Guida all'installazione e alla migrazione

La presente Guida all'installazione e alla migrazione contiene le seguenti informazioni:

Una versione PDF di questa guida è anche disponibile nella directory pdf. La directory pdf si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. 

Ulteriori informazioni su VisualAge per Java

Questo file non include informazioni dettagliate su componenti e funzioni specifiche di VisualAge per Java. Per tali informazioni, fare riferimento alle Note di rilascio del prodotto, a cui è possibile accedere selezionando Start > Programmi > IBM VisualAge per Java per Windows V4.0 > Note di rilascio. Per tutte le lingue, le note di rilascio sono incluse nel CD del prodotto (sono disponibili dopo l'installazione) e presenti sul sito web http://www.ibm.com/vadd.  

Questo file non contiene informazioni relative all'utilizzo di VisualAge per Java. Per tali informazioni fare riferimento al manuale Guida introduttiva e all'aiuto in linea. Alcune parti dell'aiuto in linea sono state raccolte in documenti PDF che è possibile visualizzare e stampare utilizzando Adobe Acrobat Reader (disponibile su http://www.adobe.com/). Non tutti i PDF sono disponibili in tutte le lingue. I file PDF sono disponibili dalla directory pdf. La directory pdf si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

Per informazioni sul contenuto di ciascun file PDF, fare riferimento all'Indice PDF (nel manuale Guida introduttiva). L'aiuto in linea contiene anche una sezione "Risorse web" con i collegamenti ipertestuali alle risorse VisualAge disponibili su Internet.

Il sito web VisualAge Developer Domain (VADD) contiene articoli tecnici, supporti didattici, esempi e FAQ, oltre ad un facile accesso agli aggiornamenti di supporti e di prodotti per VisualAge per Java. In questo sito, è possibile scaricare strumenti di sviluppo VisualAge per Java, bean riutilizzabili, wizard e toolkit di complemento per lo sviluppo di applet e servlet. Fare riferimento al sito http://www.ibm.com/vadd. Questo sito può essere utilizzato anche per richiedere funzioni di rilasci in uscita di VisualAge per Java.

Se già si è iscritti al VisualAge Developers Domain, non è necessario registrarsi nuovamente. Sarà possibile utilizzare l'ID e la parola d'ordine correnti per ottenere gli ultimi aggiornamenti di codifica e le informazioni. Se si è nuovi utenti, utilizzare il numero di iscrizione compreso nella confezione (o media kit) ricevuta. Se è stato acquistato VisualAge per Java e non si possiede un numero di iscrizione, contattare il rappresentante IBM(R).

La home page del prodotto VisualAge per Java è ubicata in http://www.ibm.com/software/ad/vajava

Indice analitico

Parte A: VisualAge per Java, Edizione Professional

1.0 Prerequisiti
2.0 Installazione
      2.1 Installazione di VisualAge per Java, Versione 4.0
      2.2 Installazione di componenti aggiuntivi dopo l'installazione iniziale
      2.3 Considerazioni sull'installazione per Windows(R) 2000
      2.4 Installazione di IBM Developer Kit, Java Technology Edition,v1.2.2
3.0 Migrazione da una versione precedente di VisualAge per Java
      3.1 Migrazione da VisualAge per Java Versione 3.5 o Versione 3.5.3
      3.2 Migrazione dalla Versione 2.0, 3.0x o 3.0x Early Adopters di VisualAge per Java
4.0 Problemi noti e limitazioni
      4.1 Problemi noti e limitazioni di installazione
      4.2 Problemi noti e limitazioni di disinstallazione

Parte B: VisualAge per Java, Edizione Enterprise

1.0 Prerequisiti
      1.1 Prerequisiti generali
      1.2 Prerequisiti specifici per componente
2.0 Installazione
      2.1 Installazione di VisualAge per Java, Versione 4.0
      2.2 Installazione di componenti aggiuntivi dopo l'installazione iniziale
      2.3 Installazione dei client di team di VisualAge per Java
      2.4 Installazione di un client con un magazzino autonomo
      2.5 Considerazioni sull'installazione e sull'utilizzo per Windows(R) 2000
      2.6 Installazione del kit IBM Developer, Java Technology Edition, v1.2.2
3.0 Migrazione da una versione precedente di VisualAge per Java
     3.1 Migrazione di un magazzino condiviso da una precedente versione di VisualAge per Java
4.0 Problemi noti e limitazioni
      4.1 Problemi noti e limitazioni di installazione
      4.2 Problemi noti e limitazioni di disinstallazione

Parte C: EMSRV (team repository server)

1.0 Prerequisiti
      1.1 Piattaforme supportate
      1.2 TCP/IP
      1.3 Correzioni Novell necessarie per eseguire EMSRV su NetWare 4.x
      1.4 Correzioni Solaris necessarie per eseguire EMSRV su Solaris     
      1.5 Sistemi di file supportati   
2.0 Installazione
     2.1 Installazione di EMSRV per Windows(R)
             2.1.1 Installazione di EMSRV come Servizio nel registro Windows
     2.2 Installazione di EMSRV per NetWare 
     2.3 Installazione di EMSRV per OS/2 (R) Warp
     2.4 Installazione di EMSRV per AIX
     2.5 Installazione di EMSRV per HP-UX/Solaris(TM)
     2.6 Installazione di EMSRV per Linux
3.0 Migrazione
      3.1 Migrazione dalla Versione 6.x/7.0 di EMSRV alla Versione 7.1
4.0 Preparazione per lo sviluppo team
      4.1 Preparazione del server team
      4.2 Verifica di un collegamento client
      4.3 Aggiunta utenti all'elenco utenti del magazzino
5.0 Limitazioni e problemi noti
      5.1 Prestazioni su connessioni di rete ad alta latenza e banda corta
      5.2 Limitazioni di collegamento TCP/IP 
      5.3 Rilevamento di collegamenti rilasciati in modo imprevisto
      5.4 Interscambio di differenti versioni di EMSRV e dei programmi di utilità EMSRV
      5.5 Limitazioni PAM
      5.6 Parole d'ordine con caratteri non-ASCII non utilizzabili per l'autenticazione con EMSRV
      5.7 Menu e finestre con caratteri corrotti su NetWare in lingua giapponese
      5.8 EMADMIN non copia la directory di risorse memorizzate

Parte D: Informazioni sulla migrazione di componenti specifici

1.0 CICS(R) Transaction Server  * +
2.0 Bean Data Access
3.0 Data Access Builder * +
4.0 Ambiente di sviluppo EJB(TM)+
5.0 Enterprise Access Builder e e-connector +
6.0 Enterprise Toolkit per AS/400(R) +
7.0 Enterprise Toolkit per OS/390(R) +
8.0 Enterprise Toolkit per Workstations * +
9.0 Controllo versione esterno
10.0 Ambiente di sviluppo IDL +
11.0 IDE (Integrated Development Environment)
 12.0 Ambiente di svulippo JSP/Servlet
13.0 Assistente per la migrazione *
14.0 Persistence Builder +
15.0 RMI Access Builder * +
16.0 Editor di composizione visiva (VCE)
17.0 Servlet Builder e Servlet Launcher  * +
18.0 Classi Swing
19.0 XMI Toolkit +

* Questi componenti non sono supportati in VisualAge per Java, Versione 4.0

+ Solo Edizione Enterprise

Parte E: Informazioni generali

1.0 Rapporto tra risorse del progetto e gestione risorse
2.0 Migrazione da OS/2 e AIX
3.0 Nuove restrizioni di sicurezza in J2SDK v.1.2.2
4.0 Nuovo strumento di controllo versione esterno (sostituisce lo strumento SCM External)
5.0 Gestione di ORB di terzi in VisualAge per Java
6.0 Contenuto del CD Funzioni aggiuntive

Appendici

Appendice A: Confronto tra funzioni di accesso dati

Parte A: VisualAge per Java, Edizione Professional

A.1.0 Prerequisiti

Questa edizione di VisualAge per Java, Versione 4.0 presenta i seguenti prerequisiti hardware e software:

Se si desidera eseguire Websphere Application Server contemporaneamente a DB2(R) e VisualAge per Java, si consigliano almeno 512 MB.

* Nota: VisualAge per Java non supporta il mouse a scorrimento Logitech. Qualsiasi mouse Logitech con driver che riassociano l'azione di scorrimento sul mouse provocheranno un errore di sistema nel momento in cui vengono utilizzati per lo scorrimento. 

A.2.0 Installazione

Questa sezione contiene informazioni sull'installazione di VisualAge per Java, Versione 4.0 Importante: Se si sta migrando da una precedente versione di VisualAge per Java, fare riferimento alla sezione 3.0 prima di installare la Versione 4.0. Per informazioni speciali relative all'installazione su Windows 2000, fare riferimento alla sezione 2.3.

Fare anche riferimento al README (ubicato nella directory READNE del CD del prodotto) per informazioni su limitazioni e problemi noti dell'ultima ora. 

A.2.1 Installazione di VisualAge per Java, Versione 4.0

Prima di installare il prodotto, verificare quanto segue:

Se si prova ad installare VisualAge per Java su Windows, Millennium Edition, verrà richiesto di aumentare il proprio spazio di ambiente. I passi descritti di seguito devono essere eseguiti prima di procedere con l'installazione, altrimenti il sistema di aiuto di VisualAge per Java non funzionerà in modo corretto. Per aumentare lo spazio di ambiente:

  1. Uscire dal pannello Installazione.
  2. Aprire Windows Explorer. Passare alla directory Windows (ad esempio, C:\Windows).
  3. Fare clic con il tastino destro del mouse su Command.com, quindi, fare clic su Proprietà dal menu concatenato. Fare clic sul separatore Memoria.
  4. Nella casella Ambiente iniziale, impostare la dimensione di ambiente iniziale su 4.096 byte. Fare clic su OK.
  5. Chiudere Windows Explorer.
  6. Riavviare il computer.
  7. Riavviare l'installazione di VisualAge per Java.

A.2.1.1 Installazione di VisualAge per Java, Versione 4.0 dal CD del prodotto

  1. Inserire il CD-ROM nell'unità CD. Se si sta migrando da una precedente versione di VisualAge per Java, consultare "Migrazione da una precedente versione di VisualAge per Java" (sezione 3.0 del presente documento) PRIMA di continuare con la procedura di installazione.
  2. Se sul sistema è disabilitata la funzione di esecuzione automatica, eseguire setup.exe dalla directory root dell'unità CD.
  3. Selezionare Installa prodotti. Selezionare Installa VisualAge per Java per iniziare l'installazione di VisualAge per Java. Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, fare riferimento alla sezione A.2.1.1.1 per informazioni sull'installazione del Distributed Debugger.
  4. Seguire le istruzioni visualizzate sullo schermo.
  5. Avviare l'IDE di VisualAge per Java.

Installazione non presidiata
Per installare VisualAge per Java, Versione 4.0 in modalità non presidiata, richiamare il seguente comando dalla directory ivj40\setup:

setup /s /v/qn

VisualAge per Java verrà automaticamente installato nella directory di default c:\Program Files\IBM\VisualAge per Java.

Per installare in modalità non presidiata in una diversa directory (ad esempio, d:\IBMVJava40), richiamare il seguente comando dalla directory ivj40\setup:

setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"

dove d:\IBMVJava40 è la directory in cui si desidera effettuare l'installazione.

A.2.1.1.1 Installazione di Distributed Debugger dal CD del prodotto
Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, è necessario installare Distributed Debugger. Distributed Debugger è supportato sui seguenti sistemi operativi: Windows, AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. Di seguito vengono fornite istruzioni di installazione per ciascun sistema operativo. Tutti i file Distributed Debugger si trovano sul CD del prodotto, nella directory Debugger.

 Distributed Debugger per Windows

  1. Eseguire setup.exe e selezionare Installazione prodotti. Quindi, selezionare Installa Distributed Debugger per installare il debugger.
Distributed Debugger per AIX  
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare idebug.tar.Z dal supporto di installazione nella directory temporanea.
  3. Passare alla directory temporanea.
  4. Decomprimere il file idebug.tar.Z mediante il comando: uncompress idebug.tar.Z
  5. Estrarre le immagini di installazione da idebug.tar immettendo il comando: tar -xvf idebug.tar
  6. Dalla root, immettere il seguente comando: installp -ac -X -V2 -g -N -d idebug
  7. E' anche possibile utilizzare SMIT con il comando: smitty install_latest

Distributed Debugger per OS/2

Seguire le istruzioni riportate in README_install.txt, reperibile nella sottodirectory Debugger\OS2 del CD del prodotto.

Distributed Debugger per HP-UX

Prerequisito: 
Java versione 1.3 è richiesto per l'installazione e per la funzione di debug Java.

  1. Creare una directory di lavoro, ad esempio /tmp/idebug
  2. Copiare install.class nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando: cd /tmp/idebug per aprirla.
  4. Dalla root, digitare il comando: java install.class
Distributed Debugger per Solaris  
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare dbgsetup e idebug.pkg nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando cd /tmp/idebug per aprirla.
  4. Rendere eseguibile "dbgsetup" eseguendo il comando: chmod +x dbgsetup
  5. Dalla root, immettere il seguente comando per installare il debugger: ./dbgsetup idebug.pkg

Distributed Debugger per Linux 

Dalla root, immettere il seguente comando per installare il debugger: rpm -Uvh DERJPICL-9-1.i386.rpm

Distributed Debugger per Linux/390 

Dalla root, immettere il seguente comando per installare il debugger: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger per OS/390

  1. Installare Distributed Debugger per Windows.
  2. Seguire le istruzioni riportate nel file README_install.txt, ubicato nella directory di installazione di base su Windows.

A.2.1.2 Installazione dall'immagine elettronica di VisualAge per Java, Versione 4.0
Per ridurre i tempi di download, l'immagine elettronica di VisualAge per Java, Edizione Professional per Windows, Versione 4.0 è divisa in parti.

A.2.1.2.1 IDE
Esistono nove parti scaricabili per l'IDE (Integrated Development Environment). Tutte le nove parti sono costituite da archivi auto-esplodenti. E' necessario installare i primi due; gli altri sono opzionali. Per i dettagli sul contenuto di ciascun archivio, fare riferimento all'elenco riportato di seguito.

Una volta scaricate le prime due parti più i file opzionali desiderati, eseguire ciascun archivio auto-esplodente ed accertarsi che ognuno venga estratto nella stessa directory temporanea. Dopo aver estratto tutti i file, andare nella directory temporanea ed eseguire setup.exe. Seguire le istruzioni visualizzate sullo schermo ed avviare l'IDE.

Se si intende lavorare in una lingua diversa dall'inglese, è necessario scaricare la parte corretta ed eseguire l'archivio auto-esplodente relativo alla propria lingua prima di eseguire setup.exe. Non è possibile cambiare o aggiungere una lingua dopo aver installato VisualAge per Java.

Se si sta lavorando con un'immagine elettronica di VisualAge per Java, non è possibile utilizzare la finestra di dialogo Aggiungi/Rimuovi programma (Start > Impostazioni > Pannello di controllo > Aggiungi/Rimuovi programmi) per installare componenti VisualAge per Java aggiuntivi dopo l'installazione iniziale. Se si prova questa operazione, si riceverà un messaggio di errore e non sarà possibile installare alcun componente aggiuntivo. Per aggiungere ulteriori componenti di VisualAge per Java è necessario eseguire setup.exe dal percorso da cui sono state estratte le parti scaricate.

Di seguito viene riportata una descrizione di ciascuna parte:

A.2.1.2.2 Distributed Debugger
E' presente una parte scaricabile separatamente per ciascun sistema operativo di destinazione supportato da Distributed Debugger. Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, è necessario scaricare e installare Distributed Debugger. Di seguito vengono fornite istruzioni di installazione per ciascun sistema operativo. Queste istruzioni e informazioni relative alle condizioni della licenza sono reperibili anche nel file readme.txt incluso in tutte le parti.

VisualAge per Java - Distributed Debugger per Windows contiene l'interfaccia utente e il motore di debug per Windows. Questa parte è rappresentata da un archivio auto-esplodente. Per procedere all'installazione, seguire questi passi:

  1. Se è stato scaricato e estratto VisualAge per Java, eseguire setup.exe e selezionare Installazione prodotti. Quindi, selezionare Installa Distributed Debugger. 
  2. Se si desidera installare Distributed Debugger senza VisualAge per Java, aprire la seguente directory da una richiesta comandi: DebugDirectory\windows (dove DebugDirectory indica la directory in cui è stato estratto Distributed Debugger) ed eseguire il seguente comando: setup.bat
VisualAge per Java - Distributed Debugger per AIX contiene il motore di debug AIX. Per procedere all'installazione, seguire queste istruzioni:
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare idebug.tar.Z dal supporto di installazione nella directory temporanea.
  3. Passare alla directory temporanea.
  4. Decomprimere il file idebug.tar.Z mediante il comando: uncompress idebug.tar.Z
  5. Estrarre le immagini di installazione da idebug.tar immettendo il comando: tar -xvf idebug.tar
  6. Dalla root, immettere il seguente comando: installp -ac -X -V2 -g -N -d idebug
  7. E' anche possibile utilizzare SMIT con il comando: smitty install_latest
VisualAge per Java - Distributed Debugger per OS/2 contiene il motore di debug OS/2. Per installarlo, seguire le istruzioni riportate in README_install.txt (incluso nella parte del Distributed Debugger per OS/2).

VisualAge per Java - Distributed Debugger per HP-UX contiene il motore di debug per HP-UX.

Prerequisito: 
Java versione 1.3 è richiesto per l'installazione e per la funzione di debug Java.

Per installarlo, decomprimere il file e seguire queste istruzioni:

  1. Creare una directory di lavoro, ad esempio /tmp/idebug
  2. Copiare install.class nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando: cd /tmp/idebug per aprirla.
  4. Dalla root, digitare il comando: java install.class
VisualAge per Java - Distributed Debugger per Solaris contiene il motore di debug per l'ambiente operativo Solaris. Per installarlo, decomprimere il file e seguire queste istruzioni:
  1. Rendere eseguibile "dbgsetup" eseguendo il comando: chmod +x dbgsetup
  2. Dalla root, immettere il seguente comando per installare il debugger: ./dbgsetup idebug.pkg

VisualAge per Java - Distributed Debugger per Linux contiene il motore di debug  per Linux. Per installarlo, decomprimere il file e installare il debugger seguendo queste istruzioni:

Dalla root, immettere il seguente comando: rpm -Uvh DERJPICL-9-1.i386.rpm

VisualAge per Java - Distributed Debugger per Linux/390 contiene il motore di debug per Linux/390. Per installarlo, decomprimere il file e installare il debugger seguendo queste istruzioni:

Dalla root, immettere il seguente comando: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger per OS/390

  1. Installare Distributed Debugger per Windows.
  2. Seguire le istruzioni riportate nel file README_install.txt, ubicato nella directory di installazione di base su Windows.

A.2.1.2.3 IBM Developer Kit 1.2.2
VisualAge per Java - IBM Developer Kit 1.2.2 contiene il kit IBM Developer, Java Technology Edition, v 1.2.2, PTF 9, per la piattaforma Windows. Si tratta di un archivio auto-esplodente.Per installarlo, eseguire il file che avvierà automaticamente il programma di installazione dopo l'estrazione dall'archivio e seguire le istruzioni.

A.2.2 Installazione di componenti aggiuntivi dopo l'installazione iniziale

Per installare componenti aggiuntivi di VisualAge per Java dopo l'installazione iniziale, inserire il CD-ROM nell'unità CD, selezionare l'installazione di VisualAge per Java e selezionare Modifica dal pannello Manutenzione programmi. Se sul sistema è disabilitata la funzione di esecuzione automatica, sarà necessario eseguire setup.exe dalla directory root dell'unità CD. Anche se si dispone di una versione elettronica di VisualAge per Java, sarà necessario eseguire manualmente setup.exe e seguire gli stessi passi.

Tutti i componenti verranno elencati nella finestra Edita funzioni, con un'indicazione relativa al corrente stato di installazione. Una 'X' rossa indica che un determinato componente non è al correntemente installato. E' possibile selezionare l'installazione di tali componenti. Non selezionare i componenti non contrassegnati dalla 'X' rossa; tali componenti sono già stati installati. 

Non è possibile installare una seconda istanza di VisualAge per Java, Versione 4.0. Non è possibile cambiare la lingua di installazione senza prima disinstallare il prodotto.

A.2.3 Considerazioni sull'installazione per Windows 2000  

Questo rilascio di VisualAge per Java continua a fornire il supporto di tolleranza (come definito da Microsoft) per Windows 2000.

La directory di installazione di default è <Program Files>\IBM\VisualAge per Java. In Windows 2000, per default, l'installazione in <Program Files> può essere eseguita solo da Administrator e utenti Standard (Power). Utenti Regular (Restricted) non possono accedere in scrittura a tale ubicazione.

A causa del design corrente di VisualAge per Java, se il prodotto viene installato in questa ubicazione e deve essere utilizzato da un utente Regular (Restricted), è necessario modificare le impostazioni di sicurezza nella directory IBM o IBM\VisualAge per Java sotto <Program> in modo da consentire l'accesso in scrittura a utenti regular. Errori in queste operazioni potrebbero provocare malfunzionamenti durante l'avvio dell'IDE.

A.2.4 Installazione di IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 

Se VisualAge per Java è stato installato dal CD del prodotto, è necessario eseguire install.exe dalla directory IBM Developer Kit per installare IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Questa directory si trova sul CD del prodotto. Se si dispone di una versione elettronica di VisualAge per Java, questa directory si trova nella propria directory temporanea (in cui sono state estratte le parti), ma non è necessario eseguire install.exe poichè il programma di installazione viene avviato automaticamente dopo essere stato estratto dall'archivio IBM Developer Kit scaricato.

Per informazioni dettagliate su IBM Developer Kit, fare riferimento al file README nella directory IBM Developer Kit.

A.3.0 Migrazione da una precedente versione di VisualAge per Java

Per informazioni sulla migrazione generale e di componenti specifici prima di iniziare il processo di migrazione, fare riferimento alla Parte D e alla Parte E.

E' possibile effettuare automaticamente la migrazione dalla Versione 3.5 o 3.5.3. La Versione 4.0 viene installata sulla  Versione 3.5 o sulla Versione 3.5.3. Fare riferimento alla sezione 3.1 per informazioni sulla migrazione da VisualAge per Java Versione 3.5 o Versione 3.5.3.

E' necessario eseguire manualmente la migrazione dalla versione 3.0x, Early Adopters.  Fare riferimento alla sezione 3.2 per informazioni sulla migrazione da VisualAge per Java, 3.0x, Early Adopters.

Se si sta attualmente utilizzando VisualAge per Java, Versione 2.0, 3.0 o 3.02 con il supporto JDK 1.1.x, non è possibile migrare automaticamente a VisualAge per Java, Versione 4.0. Tali versioni di VisualAge per Java possono infatti coesistere con VisualAge per Java, Versione 4.0. Fare riferimento alla sezione 3.2 per informazioni sulla migrazione del contenuto del magazzino e dei file di risorse da Versioni 2.0 o 3.0x di VisualAge per Java.

Non è possibile migrare da VisualAge per Java, Versione 3.5, edizione Entry Enterprise o da VisualAge per Java, Versione 3.5 o Versione 3.5.3 Edizione Enterprise a VisualAge per Java, Versione 4.0, Edizione Professional. E' necessario effettuare la migrazione alla Versione 4.0, Edizione Enterprise.

Nota: Quando si sta passando da VisualAge per Java, Versione 3.5 o Versione 3.5.3 alla Versione 4.0, il processo di installazione potrebbe sembrare bloccato. Ciò si verifica poiché la funzione "DoCosting" (che confronta i file delle versioni 3.5 o 3.5.3 con i file delle versioni 4.0) può impiegare fino a tre minuti per l'esecuzione del confronto, provocando un sensibile rallentamento del processo di installazione.

A.3.1 Migrazione dalla Versione 3.5 o dalla Versione 3.5.3

La migrazione da VisualAge per Java, Versione 3.5 o Versione 3.5.3 è automatica. Il programma di installazione della Versione 4.0 aggiorna automaticamente alla Versione 4.0 una Versione 3.5 o 3.5.3 installata.

Migrazione automatica

  1. Eseguire le procedure descritte di seguito per eseguire il backup dei dati utente. Creare copie di backup dei file di risorse e del magazzino in caso di problemi durante il processo di migrazione.
    1. Effettuare la versione dei progetti e dei pacchetti. E' possibile importare nel magazzino VisualAge per Java, Versione 4.0 solo i progetti e i pacchetti di cui è stata effettuata una versione. Per istruzioni sulla creazione di versioni, fare riferimento all'aiuto in linea di VisualAge per Java.
    2. Salvare il magazzino in una nuova ubicazione esterna alla struttura di directory di VisualAge per Java. Il percorso e il nome file del magazzino è x:\IBMVJava\ide\repository\ivj.dat, dove x:\IBMVJava è la directory di installazione di VisualAge per Java.
      Nota: Se si sta migrando dalla Versione 3.5 o 3.5.3, il magazzino comprende anche versioni delle copie dei propri file di risorse di progetto, ubicate nella directory: x:\IBMVJava\ide\repository\ivj.dat.pr. E' necessario salvare una copia della directory ivj.dat.pr al di fuori della struttura di directory di VisualAge per Java. 
  2. Per installare VisualAge per Java, Versione 4.0, fare riferimento alle istruzioni sull'installazione contenute nella sezione 2.1.
  3. Selezionare l'aggiornamento dell'installazione corrente. Non è necessario disinstallare la Versione 3.5 o 3.5.3, poiché viene automaticamente aggiornata alla Versione 4.0. La Versione 4.0 verrà automaticamente installata nella directory in cui era installata la Versione 3.5 o 3.5.3.
  4. Una volta completato l'aggiornamento dell'installazione, tutte le risorse di progetto e i dati di magazzino vengono automaticamente migrati nella nuova versione al primo avvio dell'IDE della Versione 4.0. 

In caso di problemi di installazione, è necessario migrare manualmente i dati utente. E' inoltre necessario migrare manualmente i dati utente se l'IDE non viene avviato o se l'IDE rileva un errore durante la migrazione dei dati utente. 

Migrazione manuale

  1. Verificare di aver salvato i dati del magazzino (cioè il magazzino e, se si sta migrando dalla Versione 3.5 o 3.5.3, la directory ivj.dat.pr) e i file di risorse al di fuori della struttura delle directory di VisualAge per Java.
  2. Disinstallare completamente il prodotto. Cancellare tutte le sottodirectory e i file di Versione 3.5 o 3.5.3.
  3. Riavviare ed installare la Versione 4.0.
  4. Avviare l'IDE.
  5. E' possibile importare pacchetti e progetti dal magazzino obsoleto nel nuovo magazzino. Nel Workbench, selezionare File > Importa, quindi selezionare il pulsante a selezione ciclica Magazzino e fare clic su Avanti. Nel campo Nome magazzino, immettere il percorso della copia di riserva di ivj.dat. Scegliere i progetti e i pacchetti che si desidera importare. Non sarà possibile importare progetti o pacchetti che non dispongono di versioni.Nota: E' sconsigliabile provare ad importare progetti di sistema da una precedente versione di VisualAge per Java.
  6. Per aggiungere automaticamente i progetti selezionati allo spazio di lavoro, selezionare la casella di controllo Aggiungere l'edizione del progetto più recente allo spazio di lavoro. Questa casella di controllo è disponibile solo se il pulsante a selezione ciclica Progetti è selezionato.
  7. Fare clic su Fine.
  8. Non è necessario copiare la copia di backup dei propri file di risorse nella sottodirectory x:\IBMVJava\ide\project_resources\project, dove x:\IBMVJava indica la directory di installazione di VisualAge per Java, Versione 4.0 e project indica il nome del progetto a cui sono associate le risorse.
    Quando si importano i progetti della Versione 3.5 o 3.5.3 nel magazzino, tutte le versioni di copie delle risorse di progetto (contenute nella directory ivj.dat.pr) vengono automaticamente aggiunte al magazzino. 

A.3.2 Migrazione dalla Versione 2.0, 3.0x o 3.0x Early Adopters di VisualAge per Java

E' possibile migrare manualmente i file di risorse e il contenuto del magazzino dalla Versione 2.0, 3.0x e 3.0x, Early Adopters di VisualAge per Java. Per informazioni sul ripristino di eventuali danni, fare riferimento al file dell'aiuto in linea "Riparazione di riferimenti di classe e di pacchetto".

Non è necessario disinstallare la Versione 2.0 o 3.0x o 3.0x, Early Adopters; tali versioni possono coesistere con VisualAge per Java, Versione 4.0.

Seguire tutti i passi riportati di seguito prima di disinstallare la Versione 2.0, 3.0x o 3.0x, Early Adopters, se si desidera importare i file di risorse e di magazzino di Versione 2.0, 3.0x o 3.0x Early Adopters per Java 2 Platform, Standard Edition, v1.2 nella Versione 4.0. Se non si disinstalla la Versione 2.0, 3.0x o 3.0x, Early Adopters, non è necessario eseguire i passi 2, 3, 4 e 8, ma è richiesta l'esecuzione di tutti gli altri passi.

  1. Effettuare la versione dei progetti e dei pacchetti. In questa versione di VisualAge per Java possono essere importati solo progetti e pacchetti di cui è stata eseguita una versione. Per istruzioni sulla creazione di versioni, fare riferimento all'aiuto in linea di VisualAge per Java. 
  2. Salvare il proprio magazzino in una nuova ubicazione al di fuori della struttura di directory di VisualAge per Java. Il percorso e il nome file del magazzino è x:\IBMVJava\ide\repository\ivj.dat, dove x:\IBMVJava indica la directory di installazione di VisualAge per Java.
  3. Copiare tutti i file di risorse (come file di immagini o audio) utilizzati dalle applicazioni Java in una directory esterna alla struttura di directory di VisualAge per Java. Per default, i file di risorse relativi a ciascun progetto di VisualAge per Java sono situati in directory secondarie denominate x:\IBMVJava\ide\project_resources\project, dove x:\IBMVJava è la directory di installazione di VisualAge per Java e project indica il nome del progetto al quale sono associate le risorse.
  4. Ora è possibile disinstallare la Versione 2.0, 3.0x o 3.0x, Early Adopters, ed installare la Versione 4.0. Non è necessario disinstallare la Versione 2.0 o 3.0x o 3.0x, Early Adopters; tali versioni possono coesistere con VisualAge per Java, Versione 4.0.
  5. Installare VisualAge per Java Versione 4.0 (fare riferimento alla sezione 2.1) e avviare l'IDE della Versione 4.0. 
  6. Per l'importazione di pacchetti e progetti dal vecchio magazzino al nuovo magazzino, fare riferimento all'aiuto in linea. Non sarà possibile importare progetti o pacchetti che non dispongono di versioni.Nota: E' sconsigliabile provare ad importare progetti di sistema da una precedente versione di VisualAge per Java.
  7. Copiare la copia di backup dei propri file di risorse (o crearne una copia dall'installazione 2.0/3.0x o 3.0x Early Adopters corrente se questa non è stata eliminata) nella sottodirectory x:\IBMVJava\ide\project_resources\project, dove x:\IBMVJava indica la directory di installazione di VisualAge per Java, Versione 4.0 e project indica il nome del progetto al quale sono associate le risorse.
  8. Una volta verificato che la migrazione manuale è stata eseguita correttamente, è possibile cancellare le copie di backup create nei passi 2 e 3.

A.4.0 Problemi noti e limitazioni

Fare anche riferimento al README (ubicato nella directory README del CD) per informazioni su limitazioni e problemi noti dell'ultima ora. 

A.4.1 Problemi noti e limitazioni di installazione

Di seguito è riportato un elenco di informazioni che è opportuno tener presente durante l'installazione.

A.4.1.1 Limitazioni del disco

A.4.1.2 Autorizzazione utente

A.4.1.3 Considerazioni TCP/IP

A.4.1.4 Estensione shell (Windows NT)

Se viene visualizzato un messaggio indicante che il programma di installazione ha rilevato un'estensione shell per Windows NT, l'installazione non potrà procedere. Sarà pertanto necessario effettuare i seguenti passi:

  1. Assicurarsi di avere a disposizione un disco di ripristino. Le istruzioni per la creazione di tale disco sono disponibili nella documentazione della guida di Windows.
  2. Immettere regedit.exe da un prompt dei comandi.
  3. Nell'Editor di registro, espandere la chiave
    \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  4. Selezionare il nome della shell nelle coppie nome/dati relative alla chiave sopra riportata. Importante: Prendere nota dei dati registrati per questo nome, poiché saranno necessari dopo l'installazione di IBM VisualAge per Java.
  5. Selezionare Edita > Modifica dalla barra dei menu per la coppi nome/dati della shell.
  6. Impostare il valore per il nome shell su Explorer.exe. Fare clic su OK.
  7. Selezionare Registro > Esci dalla barra dei menu.
  8. Riavviare e completare l'installazione di IBM VisualAge per Java.
  9. Una volta completata l'installazione, ripristinare la voce di registro precedente come segue:
    a. Immettere regedit.exe da un prompt dei comandi.
    b. Nell'Editor di registro, espandere la chiave \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    c. Selezionare il nome della shell nelle coppie nome/dati della chiave riportata sopra.
    d. Selezionare Edita > Modifica dalla barra dei menu per la coppia nome/dati della shell.
    e. Ripristinare il valore del nome della shell sul valore registrato nel Passo 4. Fare clic su OK.
    f. Selezionare Registro > Esci dalla barra dei menu.

A.4.1.5 Ripristino da un'installazione non riuscita

Se l'installazione non riesce, è necessario rimuovere tutti i file della Versione 4.0 che sono stati installati. Se la directory in cui si desidera installare VisualAge per Java è vuota, il processo di installazione viene riportato indietro e ogni file installato viene rimosso. Se si desidera, è possibile cancellare la directory vuota, ma ciò non è necessario. Tuttavia, se la directory contiene file, è necessario avviare nuovamente il processo di installazione. Questo verrà aperto in modalità di manutenzione ed è necessario selezionare l'eliminazione dell'installazione parziale della Versione 4.0 prima di installare di nuovo il prodotto.

Sarà anche necessario cancellare la voce di registro:

\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge per Java per Windows

e seguire le istruzioni qui riportate:

  1. Assicurarsi di avere a disposizione un disco di ripristino. Le istruzioni per la creazione di tale disco sono disponibili nella documentazione della guida di Windows.
  2. Immettere regedit.exe da un prompt dei comandi.
  3. Nell'Editor di registro, espandere e selezionare la chiave
    \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
  4. Selezionare Edita > Cancella dalla barra dei menu per questa chiave.
  5. Selezionare Sì quando viene visualizzata la richiesta di conferma della cancellazione della chiave.
  6. Selezionare Registro > Esci dalla barra menu.

Se qualsiasi file NetQuestion è stato installato prima del malfunzionamento dell'installazione, sarà necessario cancellarlo.

  1. Aprire un nuovo prompt di comandi. Controllare se sono stati installati file NetQuestion digitando quanto segue nel prompt di comandi appena aperto: set imninstsrv. Questo comando fornirà l'ubicazione in cui è installato NetQuestion. Ad esempio,

    IMNINSTSRV=C:\imnnq_nt

    L'ubicazione della directory NetQuestion potrebbe essere diversa, in base all'unità su cui si installa VisualAge per Java e al sistema operativo che si sta utilizzando. Se la variabile è impostata (cioè se si dispone di un'ubicazione in cui è installato NetQuestion), procedere al passo 2. 

    Se si riceve un messaggio di errore del tipo "Variabile di ambiente imninstsrv non definita", nessun file NetQuestion è stato installato oppure l'installazione di NetQuestion non è stata completata correttamente. Se ciò accade, selezionare Start > Trova > File o cartelle e ricercare il seguente file sul sistema: vahelp.cfg. Se tale file viene localizzato in una qualsiasi directory il cui nome inizia con "imnnq" (ad esempio, imnnq_NT o imnnq_98), cancellarlo. Non è necessario eseguire i passi 2 e 3. 

  2. Andare alla directory NetQuestion (riportata nelle informazioni che seguono IMNINSTSRV=)
  3. Digitare vahcfg remove /p vj32

Questa operazione rimuove tutti i file NetQuestion installati da VisualAge per Java. Ciò non influenzerà i file NetQuestion installati da altri prodotti (ad esempio, DB2).

Se non è ancora stato fatto, eseguire il backup del magazzino e dei file di risorse. Fare riferimento alla Parte A, sezione 3.1 per informazioni sull'esecuzione di questa operazione. 

Riavviare e reinstallare il prodotto dopo aver eseguito tutti i passi descritti. Se l'aiuto non funziona dopo aver reinstallato VisualAge per Java, fare riferimento alla Guida alla risoluzione dei problemi. La Guida alla risoluzione dei problemi (trshoot.htm) si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Dopo aver installato VisualAge per Java, sarà reperibile anche in X:\IBMVJava, dove X:\IBMVJava indica la directory di installazione di VisualAge per Java.

A.4.1.6 Errori del Programma di installazione Windows

Di seguito è riportato un elenco degli errori di Windows Installer da tenere presente durante l'installazione.

Errore 1603 (solo Windows NT 4.0)

Se si riceve il messaggio di errore 1603 mentre si sta installando VisualAge per Java, significa che l'inizializzazione di Windows Installer non è riuscita e l'installazione non può procedere. 

Alcuni prodotti (come VisualCafe Symantec) installano automaticamente un file denominato sfc.dll quando vengono installati su qualsiasi piattaforma Windows. Questo file viene utilizzato solo su Windows 2000, richiamato da Windows Installer per il processo di protezione. 

Se un file con questo nome è ubicato sul PATH di Windows NT 4.0, Windows Installer tenterà di caricarlo, anche se sfc.dll non è applicabile a Windows 2000. In seguito a ciò, Windows Installer non riuscirà a funzionare. 

Per evitare questo problema:

  1. Selezionare Start > Trova > File o cartelle e ricercare il file sfc.dll sul proprio sistema.
  2. Ridenominare temporaneamente il file sfc.dll (la versione che si trova sul PATH di Windows NT 4.0) in sfc.old.
  3. Installare VisualAge per Java.
  4. Dopo aver installato VisualAge per Java, ridenominare sfc.old in sfc.dll.

Errore Fatal LoadLibrary()

L'errore Fatal LoadLibrary() si verifica quando uno o più kernel di installazione di VisualAge per Java (IKernels) non sono stati registrati correttamente da Windows Installer. Per risolvere il problema, è necessario cancellare la directory di InstallShield in cui sono ubicati i file IKernal e reinstallare VisualAge per Java seguendo questi passi:

  1. Se necessario, uscire dall'installazione.
  2. Cancellare la directory: x:\Program Files\Common Files\InstallShield, dove x indica l'unità su cui l'utente ha tentato di installare VisualAge per Java.
  3. Reinstallare il prodotto. 

Errore 1631 o Errore interno 2755 (solo Windows NT 4.0)

Se si installa VisualAge per Java su Windows NT 4.0, si potrebbe ricevere uno dei seguenti messaggi di errore:

Se si ricevono questi messaggi di errore, le chiavi di registro potrebbero avere valori nulli. Quando si avvia l'installazione di VisualAge per Java, il file userenv.dll proverà ad analizzare diverse chiavi di registro e, se qualcuna di queste ha valori nulli, l'installazione non riuscirà e verrà visualizzato uno dei precedenti messaggi di errore.

Per risolvere questo problema, rimuovere le variabili di ambiente con valori nulli oppure modificarle (cambiare il valore nullo in un valore valido) prima di installare VisualAge per Java. Dopo aver installato VisualAge per Java, è possibile riportarle ai valori originali.

Attenzione: Procedere alla rimozione o alla modifica delle variabili nulle con molta attenzione. Considerare qualsiasi impatto potenziale che potrebbe verificarsi prima di procedere.

Errori interni 2381, 1303, 1310, 1313 (solo Windows NT)

Se si sta provando ad installare VisualAge per Java e sono effettive una o tutte le seguenti condizioni:

si potrebbe ricevere uno o più messaggi di errore simili ai seguenti:

Questo problema risulta essersi verificato quando sono presenti solo autorizzazioni per la lettura sulle seguenti cartelle:

\Program Files\IBM\VisualAge for Java
\WinNT\Installer

Per risolvere il problema, accertarsi di disporre delle autorizzazioni necessarie per le proprie unità o directory. A tale scopo, seguire questi passi:

  1. In Windows Explorer, selezionare l'unità o la directory desiderata.
  2. Fare clic con il tastino destro del mouse sulla cartella e selezionare Proprietà dal menu a discesa.
  3. Selezionare il separatore Protezione. Fare clic su Autorizzazioni.
  4. Selezionare Tutti. Dal menu a discesa Tipo di accesso, selezionare Accesso completo.
  5. Selezionare la casella di selezione Sostituire autorizzazioni su sottodirectory.
  6. Fare clic su OK.
  7. Fare clic su Sì quando viene richiesto di confermare la sostituzione delle autorizzazioni su tutte le sottodirectory.
  8. Fare clic su OK.
  9. Installare VisualAge per Java.

Errore interno 2735 Avvio del motore

Se si riceve l'errore 2735, risolverlo eseguendo questi passi:

  1. Ricercare i seguenti file nella directory di sistema 32 Windows:
  2. Ridenominare shd401lc.dll come shd401lc.old.
  3. Ridenominare shdoclc.dll come shdoclc.old.
  4. Selezionare Start > Esegui per aprire la finestra di dialogo Esegui. Eseguire i seguenti comandi per deregistrare i file .dll. 
  5. Registrare queste dll eseguendo i comandi riportati di seguito dalla finestra di dialogo Esegui:
  6. Installare VisualAge per Java.

Errore 1606/Errore interno 2707

Se si riceve il seguente messaggio di errore, il valore del file di registro degli strumenti di gestione comuni potrebbe non essere corretto:

Errore 1606. Impossibile accedere all'ubicazione di rete \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Errore interno 2707. INSTALLDIR.

E' necessario editare il valore del file di registro degli strumenti di gestione comuni prima di poter installare VisualAge per Java. A tale scopo, seguire questi passi:

  1. Richiamare regedit.exe da una richiesta comandi.
  2. Espandere e selezionare la chiave
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder
  3. Selezionare Strumenti di gestione comuni.
  4. Selezionare Edita > Modifica.
  5. Nel campo Dati di valore, immettere: %SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools
  6. Fare clic su OK.
  7. Selezionare Registro > Esci dalla barra menu.
  8. Installare VisualAge per Java.

A.4.2 Problemi noti e limitazioni di disinstallazione

Di seguito è riportato un elenco di informazioni che è opportuno tener presente durante la disinstallazione di VisualAge per Java.

A.4.2.1 Spazio su disco

Sull'unità del sistema Windows sono necessari almeno 2MB di spazio libero; inoltre, è necessario che le variabili di ambiente TEMP o TMP siano indirizzate verso una directory temporanea valida con almeno 5MB di spazio libero.

A.4.2.2 Disinstallazione di Distributed Debugger

Se Distributed Debugger è stato installato come parte dell'installazione di VisualAge per Java, è necessario disinstallare VisualAge per Java prima di disinstallare Distributed Debugger. Dopo aver disinstallato VisualAge per Java, è possibile disinstallare Distributed Debugger dalla directory di installazione del debugger eseguendo il programma di disinstallazione.

Se è stato disinstallato VisualAge per Java e non è possibile disinstallare Distributed Debugger, è necessario cancellare la chiave di registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java

e provare nuovamente a disinstallare il debugger. NON effettuare questi passi se si sta utilizzando Distributed Debugger con altri prodotti, altrimenti non sarà possibile utilizzare il debugger dopo aver cancellato la chiave di registro.

Seguire questi passi:

  1. Immettere regedit.exe da una richiesta comandi.
  2. Nell'Editor di registro, espandere e selezionare la chiave:
    HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
  3. Selezionare Edita > Cancella dalla barra dei menu per questa chiave.
  4. Selezionare Sì quando viene visualizzata la richiesta di conferma della cancellazione della chiave.
  5. Selezionare Registro > Esci dalla barra menu.

Allo stesso modo, impostare il valore della seguente chiave di registro su 1:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount

A.4.2.3 Variabili di ambiente (Windows 98)

Quando si disinstalla VisualAge per Java su Windows 98, è possibile che vengano lasciate alcune voci di ambiente nel file autoexec.bat. Di solito tali voci non causano problemi, a meno che non si eseguano frequenti operazioni di disinstallazione e reinstallazione del prodotto. E' possibile che siano presenti istruzioni di percorso in conflitto che impediscono il funzionamento dell'aiuto in linea oppure che lo spazio di percorso non sia sufficiente, cosa che impedirebbe la corretta reinstallazione del prodotto.

Per risolvere tali problemi:

  1. Effettuare una copia di backup del file autoexec.bat.
  2. Verificare l'eventuale presenza di un altro programma che richiede il motore di ricerca HTML (come DB2) sul sistema eseguendo i passi riportati di seguito:
    a) Disinstallare VisualAge per Java e riavviare il sistema.
    b) Immettere regedit.exe da una richiesta comandi e, nell'Editor di registro, espandere la struttura di HKEY_LOCAL_MACHINE\SOFTWARE\. Se in questa struttura è presente una directory IBM, espanderla per vedere se contiene una directory NetQuestion. In caso positivo, è probabile che si stia utilizzando il motore di ricerca con un altro prodotto IBM.
  3. Se non si sta utilizzando il motore di ricerca HTML per un altro prodotto, eliminare qualsiasi immissione IMN o IMQ dal proprio file autoexec.bat prima di reinstallare VisualAge per Java.
  4. Se, invece, si sta utilizzando il motore di ricerca HTML per un altro prodotto, cancellare ogni duplicato di tali immissioni dal file autoexec.bat:
    IMNINST
    IMNINSTSRV
    IMNNQ
    IMNNQ_95
    IMQCONFIGCL
    IMQCONFIGSRV
    Cancellare anche voci duplicate della riga IF EXIST X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
  5. Assicurarsi di non eliminare le voci originali quando si eliminano le copie. Se non si è certi di quali siano le voci originali, determinare l'ubicazione in cui il sistema considera che deve essere installato NetQuestion. Seguire questi passi:
    1. Immettere regedit.exe da un prompt dei comandi.
    2. Nell'Editor di registro, espandere la chiave
      \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation Directory
    3. Il valore di directory all'interno di questa chiave indica il percorso in cui è installato NetQuestion. Per il corretto funzionamento di NetQuestion, alcune variabili di ambiente contengono questa directory come parte del proprio valore.

      Se si rileva una o più delle variabili di ambiente riportate in precedenza che include una directory diversa da quella trovata nel registro come parte del proprio valore, è necessario cancellarla.

A.4.2.4 Disinstallazione di NetQuestion

Quando si sta disinstallando VisualAge per Java, NetQuestion potrebbe non essere disinstallato. Si possono verificare dei problemi se NetQuestion non viene disinstallato quando si tenta di installare nuovamente il prodotto. 

Per eliminare i file NetQuestion installati da VisualAge per Java, seguire questi passi. Ciò non influenzerà i file NetQuestion installati da altri prodotti (ad esempio, DB2).

  1. Per trovare la directory NetQuestion, digitare quanto segue in un prompt di comandi: set imninstsrv. Questo comando fornirà l'ubicazione in cui è installato NetQuestion. Ad esempio,

    IMNINSTSRV=C:\imnnq_nt

    L'ubicazione della directory NetQuestion potrebbe essere diversa, in base all'unità su cui è installato VisualAge per Java e al sistema operativo che si sta utilizzando. Se si riceve un messaggio di errore del tipo "Variabile di ambiente imninstsrv non definita", tutti i file NetQuestion sono stati disinstallati.

  2. Andare alla directory NetQuestion (riportata nelle informazioni che seguono IMNINSTSRV=)
  3. Digitare vahcfg remove /p vj32

In questo modo, tutti i file NetQuestion installati da VisualAge per Java vengono rimossi. 

Se l'aiuto non funziona dopo aver re-installato VisualAge per Java, fare riferimento alla Guida alla risoluzione dei problemi per ulteriori informazioni sul ripristino da malfunzionamenti dell'aiuto. La Guida alla risoluzione dei problemi (trshoot.htm) si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Dopo aver installato VisualAge per Java, sarà reperibile anche in X:\IBMVJava, dove X:\IBMVJava indica la directory di installazione di VisualAge per Java.

Parte B: VisualAge per Java, Edizione Enterprise

B.1.0 Prerequisiti

B.1.1 Prerequisiti generali

Questa edizione di VisualAge per Java, Versione 4.0 presenta i seguenti prerequisiti hardware e software:

Se si desidera eseguire Websphere Application Server contemporaneamente a DB2 e VisualAge per Java, si consigliano almeno 512 MB.

Se si sta lavorando in un ambiente team, è necessario utilizzare EMSRV, Versione 7.1. Per informazioni sul passaggio dalla Versione 6.x o 7.0 alla Versione 7.1, fare riferimento alla Parte C. 

* Nota: VisualAge per Java non supporta il mouse a scorrimento Logitech. Tutti i mouse Logitech con driver che riassociano l'azione di scorrimento sul mouse, causano un errore di sistema nel momento in cui vengono utilizzati per lo scorrimento.

B.1.2 Prerequisiti specifici per componente

Alcuni componenti hanno prerequisiti specifici:

B.2.0 Installazione

Questa sezione contiene informazioni sull'installazione di VisualAge per Java, Versione 4.0. Importante: Se si sta migrando da una precedente versione di VisualAge per Java, fare riferimento alla sezione 3.0 riportata di seguito prima di procedere con l'installazione di VisualAge per Java, Versione 4.0. Per informazioni particolari relative all'installazione su Windows 2000, fare riferimento alla sezione 2.5.

Fare anche riferimento al README (ubicato nella directory root del CD del prodotto) per informazioni su limitazioni e problemi noti dell'ultima ora.

Important : A causa di una limitazione nel supporto del CDFS (CD-ROM file system) su Windows 98, l'installazione di alcuni file di connector e-business dal CD-ROM potrebbe non riuscire e determinare la visualizzazione di una o più finestre di dialogo di errore, riportate di seguito, in base ai connector selezionati:

Tutti i file non installati sono memorizzati in un file zip (econnfix.zip) ubicato nella root del CD del prodotto. Se si sta provando ad installare VisualAge per Java su Windows 98 e si riceve uno dei messaggi descritti in precedenza, decomprimere econnfix.zip nella directory in cui è stato installato il prodotto (ad esempio, eseguendo il comando unzip econnfix.zip -d c:\Program Files\IBM\VisualAge per Java\ dove c:\Program Files\IBM\VisualAge per Java\ rappresenta la directory di installazione del prodotto). Una volta che tali file sono posizionati, i connector funzioneranno correttamente.

B.2.1 Installazione di VisualAge per Java, Versione 4.0, Edizione Enterprise

Prima di installare il prodotto, verificare quanto segue:

Se si prova ad installare VisualAge per Java su Windows, Millennium Edition, verrà richiesto di aumentare il proprio spazio di ambiente. I passi descritti di seguito devono essere eseguiti prima di procedere con l'installazione, altrimenti il sistema di aiuto di VisualAge per Java non funzionerà in modo corretto. Per aumentare lo spazio di ambiente:

  1. Uscire dal pannello Installazione.
  2. Aprire Windows Explorer. Passare alla directory Windows (ad esempio, C:\Windows).
  3. Fare clic con il tastino destro del mouse su Command.com, quindi, fare clic su Proprietà dal menu concatenato. Fare clic sul separatore Memoria.
  4. Nella casella Ambiente iniziale, impostare la dimensione di ambiente iniziale su 4.096 byte. Fare clic su OK.
  5. Chiudere Windows Explorer.
  6. Riavviare il computer.
  7. Riavviare l'installazione di VisualAge per Java.

E' necessario eseguire le seguenti istruzioni, sia se si stanno installando i client team di VisualAge per Java o se si sta installando un client con un magazzino locale. Fare riferimento alla sezione 2.3 per i dettagli sull'installazione di un client team oppure alla sezione 2.4 per i dettagli sull'installazione di un magazzino locale.

B.2.1.1 Installazione di VisualAge per Java, Versione 4.0 dal CD del prodotto

  1. Se si sta migrando da una precedente versione di VisualAge per Java, consultare "Migrazione da una precedente versione di VisualAge per Java", sezione 3.0 di questo documento, PRIMA di intraprendere la procedura di installazione.
  2. Inserire il CD-ROM nell'unità CD. 
  3. Se sul sistema è disabilitata la funzione di esecuzione automatica, eseguire setup.exe dalla directory root dell'unità CD.
  4. Selezionare Installa prodotti. Selezionare Installa VisualAge per Java per iniziare l'installazione di VisualAge per Java. Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, fare riferimento alla sezione B.2.1.1.1 per informazioni sull'installazione del Distributed Debugger. 
  5. Seguire le istruzioni visualizzate sullo schermo.
  6. Avviare l'IDE di VisualAge per Java.

Installazione non presidiata
Per installare VisualAge per Java, Versione 4.0 in modalità non presidiata, richiamare il seguente comando dalla directory ivj40\setup:

setup /s /v/qn

VisualAge per Java verrà automaticamente installato nella directory di default c:\Program Files\IBM\VisualAge per Java.

Per installare in modalità non presidiata in una diversa directory (ad esempio, d:\IBMVJava40), richiamare il seguente comando dalla directory ivj40\setup:

setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"

dove d:\IBMVJava40 è la directory in cui si desidera effettuare l'installazione.

Nota: Non è possibile collegarsi a un magazzino condiviso quando si installa VisualAge per Java in modalità non presidiata; quando si effettua questo tipo di installazione, è possibile collegarsi solo ad un magazzino locale. Se si desidera eseguire l'installazione non presidiata e continuare a lavorare in un ambiente team, effettuare l'installazione localmente e, quindi, collegarsi al magazzino condiviso dopo aver installato il prodotto e avviato l'IDE. Per istruzioni su come installare localmente e lavorare in un ambiente team, fare riferimento al file team.pdf ubicato nella directory pdf. La directory pdf si trova sul CD VisualAge per Java, Edizione Enterprise, Funzioni aggiuntive. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

B.2.1.1.1 Installazione di Distributed Debugger dal CD del prodotto
Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, è necessario installare Distributed Debugger. Distributed Debugger è supportato sui seguenti sistemi operativi: Windows, AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. Di seguito vengono fornite istruzioni di installazione per ciascun sistema operativo. Tutti i file Distributed Debugger si trovano sul CD Funzioni aggiuntive.

 Distributed Debugger per Windows

  1. E' possibile installare Distributed Debugger dal CD Funzioni aggiuntive. Dal pannello Installazione delle Funzioni aggiuntive, selezionare Installa prodotti e Installa Distributed Debugger.
Distributed Debugger per AIX  
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare idebug.tar.Z dal supporto di installazione nella directory temporanea.
  3. Passare alla directory temporanea.
  4. Decomprimere il file idebug.tar.Z mediante il comando: uncompress idebug.tar.Z
  5. Estrarre le immagini di installazione da idebug.tar immettendo il comando: tar -xvf idebug.tar
  6. Dalla root, immettere il seguente comando: installp -ac -X -V2 -g -N -d idebug
  7. E' anche possibile utilizzare SMIT con il comando: smitty install_latest

Distributed Debugger per OS/2

Seguire le istruzioni riportate in README_install.txt, reperibile nella sottodirectory Debugger\OS2 del CD Funzioni aggiuntive.

Distributed Debugger per HP-UX

Prerequisito: 
Java versione 1.3 è richiesto per l'installazione e per la funzione di debug Java.

  1. Creare una directory di lavoro, ad esempio /tmp/idebug
  2. Copiare install.class nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando: cd /tmp/idebug per aprirla.
  4. Dalla root, digitare il comando: java install.class
Distributed Debugger per Solaris  
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare dbgsetup e idebug.pkg nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando cd /tmp/idebug per aprirla.
  4. Rendere eseguibile "dbgsetup" eseguendo il comando: chmod +x dbgsetup
  5. Dalla root, immettere il seguente comando per installare il debugger: ./dbgsetup idebug.pkg

Distributed Debugger per Linux 

Dalla root, immettere il seguente comando per installare il debugger: rpm -Uvh DERJPICL-9-1.i386.rpm

Distributed Debugger per Linux/390 

Dalla root, immettere il seguente comando per installare il debugger: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger per OS/390

  1. Installare Distributed Debugger per Windows.
  2. Seguire le istruzioni riportate in README_install.txt, reperibile nella sottodirectory Debugger\OS390 del CD del prodotto.

B.2.1.1.2 Installazione della versione beta di componenti J2EE 
 Questo release di VisualAge per Java include una versione beta di vari componenti della piattaforma Java 2, Enterprise Edition (J2EE (TM)). Sun Microsystems Inc. non ha ufficialmente rilasciato questi componenti J2EE. Nello specifico, questo release di VisualAge per Java include una versione beta dei seguenti componenti J2EE:

I componenti beta sono ubicati nella directory secondaria extras\BetaJ2EEConnectors del CD Funzioni aggiuntive. Se si desidera utilizzare questi componenti beta, fare riferimento al file README nella directory secondaria BetaJ2EEConnectors contenente istruzioni di installazione relative ai componenti. 

B.2.1.2. Installazione dall'immagine elettronica di VisualAge per Java, Versione 4.0
Per ridurre i tempi di download, l'immagine elettronica di VisualAge per Java, Edizione Enterprise per Windows, Versione 4.0 è divisa in parti.

B.2.1.2.1 IDE
Sono presenti quattordici parti scaricabili per l'IDE (Integrated Development Environment). Tutte sono costituite da archivi auto-esplodenti. E' necessario installare i primi due; gli altri sono opzionali. Per i dettagli sul contenuto di ciascun archivio, fare riferimento all'elenco riportato di seguito.

Una volta scaricate le prime due parti più i file opzionali desiderati, eseguire ciascun archivio auto-esplodente ed accertarsi che ognuno venga estratto nella stessa directory temporanea. Dopo aver estratto tutte le parti, andare nella directory temporanea ed eseguire setup.exe. Seguire le istruzioni visualizzate sullo schermo ed avviare l'IDE.

Se si intende lavorare in una lingua diversa dall'inglese, è necessario scaricare la parte corretta ed eseguire l'archivio auto-esplodente relativo alla propria lingua prima di eseguire setup.exe. Non è possibile cambiare o aggiungere una lingua dopo aver installato VisualAge per Java.

Se si sta lavorando con un'immagine elettronica di VisualAge per Java, non è possibile utilizzare la finestra di dialogo Aggiungi/Rimuovi programma (Start > Impostazioni > Pannello di controllo > Aggiungi/Rimuovi programmi) per installare componenti VisualAge per Java aggiuntivi dopo l'installazione iniziale. Se si prova questa operazione, si riceverà un messaggio di errore e non sarà possibile installare alcun componente aggiuntivo. Per aggiungere ulteriori componenti di VisualAge per Java è necessario eseguire setup.exe dal percorso da cui sono state estratte le parti scaricate.

Di seguito viene riportata una descrizione di ciascuna parte:

B.2.1.2.2. Distributed Debugger
E' presente una parte scaricabile separatamente per ciascun sistema operativo di destinazione supportato da Distributed Debugger.Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, è necessario scaricare e installare Distributed Debugger. Di seguito vengono fornite istruzioni di installazione per ciascun sistema operativo. Queste istruzioni e informazioni relative alle condizioni della licenza sono reperibili anche nel file readme-1st.txt incluso in tutte le parti.

VisualAge per Java - Distributed Debugger per Windows contiene l'interfaccia utente e il motore di debug per Windows. Questa parte è rappresentata da un archivio auto-esplodente. Per procedere all'installazione, seguire questi passi:

  1. Se è stato scaricato e estratto VisualAge per Java, eseguire setup.exe e selezionare Installazione prodotti. Quindi, selezionare Installa Distributed Debugger. 
  2. Se si desidera installare Distributed Debugger senza VisualAge per Java, aprire la seguente directory da una richiesta comandi: DebugDirectory\windows (dove DebugDirectory indica la directory in cui è stato estratto Distributed Debugger) ed eseguire il seguente comando: setup.bat
VisualAge per Java - Distributed Debugger per AIX contiene il motore di debug AIX. Per procedere all'installazione, seguire queste istruzioni:
  1. Creare una directory temporanea, ad esempio /tmp/idebug
  2. Copiare idebug.tar.Z dal supporto di installazione nella directory temporanea.
  3. Passare alla directory temporanea.
  4. Decomprimere il file idebug.tar.Z mediante il comando: uncompress idebug.tar.Z
  5. Estrarre le immagini di installazione da idebug.tar immettendo il comando: tar -xvf idebug.tar
  6. Dalla root, immettere il seguente comando: installp -ac -X -V2 -g -N -d idebug
  7. E' anche possibile utilizzare SMIT con il comando: smitty install_latest

VisualAge per Java - Distributed Debugger per OS/2 contiene il motore di debug OS/2. Per installarlo, seguire le istruzioni riportate in README_install.txt (incluso nella parte del Distributed Debugger per OS/2).

VisualAge per Java - Distributed Debugger per HP-UX contiene il motore di debug per HP-UX.

Prerequisito: 
Java versione 1.3 è richiesto per l'installazione e per la funzione di debug Java.

Per installarlo, decomprimere il file e seguire queste istruzioni:

  1. Creare una directory di lavoro, ad esempio /tmp/idebug
  2. Copiare install.class nella directory temporanea.
  3. Da una richiesta comandi, aprire la directory temporanea. Se tale directory è /tmp/idebug, immettere il comando: cd /tmp/idebug per aprirla.
  4. Dalla root, digitare il comando: java install.class
VisualAge per Java - Distributed Debugger per Solaris contiene il motore di debug per l'ambiente operativo Solaris. Per installarlo, decomprimere il file e seguire queste istruzioni:
  1. Rendere eseguibile "dbgsetup" eseguendo il comando: chmod +x dbgsetup
  2. Dalla root, immettere il seguente comando per installare il debugger: ./dbgsetup idebug.pkg

VisualAge per Java - Distributed Debugger per Linux contiene il motore di debug  per Linux. Per installarlo, decomprimere il file e installare il debugger seguendo queste istruzioni:

Dalla root, immettere il seguente comando: rpm -Uvh DERJPICL-9-1.i386.rpm

VisualAge per Java - Distributed Debugger per Linux/390 contiene il motore di debug per Linux/390. Per installarlo, decomprimere il file e installare il debugger seguendo queste istruzioni:

Dalla root, immettere il seguente comando: rpm -Uvh DERJPICL-9-1.s390.rpm

Distributed Debugger per OS/390

  1. Installare Distributed Debugger per Windows.
  2. Seguire le istruzioni riportate nel file README_install.txt, ubicato nella directory di installazione di base su Windows.

B.2.1.2.3 EMSRV (team server)
VisualAge per Java - EMSRV 7.1 contiene il programma del server di magazzino per l'ambiente di sviluppo team. Una singola parte di archivio contiene la codifica server per Windows, AIX, OS/2, NetWare, HP-UX, Linux e Solaris, in formato file ZIP. Per installare, decomprimere questa parte e seguire le istruzioni in instmigr.htm.

B.2.1.2.4 IBM Developer Kit 1.2.2 
VisualAge per Java - IBM Developer Kit 1.2.2 contiene IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, per la piattaforma Windows. Si tratta di un archivio auto-esplodente. Per installarlo, eseguire il file che avvierà automaticamente il programma di installazione dopo essere stato estratto dall'archivio e seguire le istruzioni. 

B.2.2 Installazione di componenti aggiuntivi dopo l'installazione iniziale

Per installare componenti aggiuntivi di VisualAge per Java dopo l'installazione iniziale, inserire il CD-ROM nell'unità CD, selezionare l'installazione di VisualAge per Java e selezionare Modifica dal pannello Manutenzione programmi. Se sul sistema è disabilitata la funzione di esecuzione automatica, sarà necessario eseguire setup.exe dalla directory root dell'unità CD. Anche se si dispone di una versione elettronica di VisualAge per Java, sarà necessario eseguire manualmente setup.exe e seguire gli stessi passi.

Tutti i componenti verranno elencati nella finestra Edita funzioni, con un'indicazione relativa al corrente stato di installazione. Una 'X' rossa indica che un determinato componente non è al correntemente installato. E' possibile selezionare l'installazione di tali componenti. Non selezionare i componenti non contrassegnati dalla 'X' rossa; tali componenti sono già stati installati. 

Non è possibile installare una seconda istanza di VisualAge per Java, Versione 4.0. Non è possibile cambiare la lingua di installazione senza prima disinstallare il prodotto.

B.2.3 Installazione dei client team di VisualAge per Java

Prima che ciascun membro del team di sviluppo possa seguire questi passi, il responsabile EMSRV deve aver impostato ed avviato il server, verificato il collegamento dei client ed aggiunto gli sviluppatori del team all'elenco utenti del magazzino. Per l'esecuzione di queste attività, fare riferimento alla Parte C di questa guida. La Parte C fornisce anche informazioni sulla migrazione di un magazzino del team.

Nelle seguenti istruzioni, si suppone che il magazzino condiviso installato sul server sia denominato ivj.dat. EMSRV, Versione 7.1 deve essere stato installato sul proprio server. Se si prova a collegarsi ad una precedente versione di EMSRV, si potrebbe ricevere un messaggio di errore.

  1. Prima di avviare l'installazione di VisualAge per Java, Versione 4.0, contattare il responsabile per ottenere le seguenti informazioni:
  2. Avviare l'installazione di VisualAge per Java, Versione 4.0. Per dettagli sull'installazione, fare riferimento alla sezione 2.0. Se si sta migrando da una versione precedente di VisualAge per Java, consultare la sezione 3.0 per i dettagli sul processo di migrazione.
  3. Quando richiesto dal programma di installazione, specificare che si desidera utilizzare un magazzino ubicato su un server. Se, anziché operare sempre come client collegato ad un magazzino condiviso, si preferisce disporre di un magazzino locale sulla propria stazione di lavoro per lavorare in modo autonomo, consultare le istruzioni alternative riportate di seguito nella sezione 2.4. Fornire il nome host TCP/IP del server (o l'indirizzo IP) e il nome del magazzino, ottenuti dal proprio responsabile. Se il responsabile non ha specificato una directory di lavoro all'avvio del programma EMSRV, sarà necessario fornire un nome completo al magazzino con informazioni sul percorso del server relativo a quel file. Il programma di installazione inserisce automaticamente l'indirizzo del server e le informazioni del magazzino nel file ide.ini del client.
  4. Verrà richiesta la selezione di un nome di proprietario per lo spazio di lavoro dall'elenco degli utenti del magazzino impostato dal responsabile. Selezionare il proprio nome utente. Se la protezione con parola d'ordine è stata abilitata, sarà necessario fornire la parola d'ordine dell'utente.

    Una barra di avanzamento indica che il collegamento dello spazio di lavoro al magazzino è in corso. Se al posto di un elenco utenti viene visualizzato un messaggio che indica che si è verificato un errore non recuperabile, potrebbe essersi verificata una delle seguenti situazioni:
    1. Il server non è attivo.
    2. E' stato specificato un nome server non corretto durante l'installazione di VisualAge per Java sulla stazione di lavoro.
    3. E' stato specificato un nome di magazzino non corretto durante l'installazione.

    E' possibile correggere le informazioni relative al server o al magazzino editando il file ide.ini sul client del team.

B.2.4 Installazione di un client con un magazzino autonomo

E' possibile disporre di un proprio magazzino di codifica di origine VisualAge per Java sulla stazione di lavoro, da utilizzare quando non si è collegati al magazzino condiviso. In tal caso, quando si installa VisualAge per Java, Versione 4.0 sulla stazione di lavoro, specificare che tale magazzino sarà ubicato sulla macchina locale anziché sul server. Il programma di installazione creerà un apposito magazzino.

Quando si desidera utilizzare il magazzino condiviso su un server team, fare riferimento all'aiuto in linea oppure al file team.pdf. Il file team.pdf si trova nella directory pdf. La directory pdf si trova sul CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

B.2.5 Considerazioni sull'installazione e sull'utilizzo per Windows 2000  

Questo rilascio di VisualAge per Java continua a fornire il supporto di tolleranza (come definito da Microsoft) per Windows 2000. 

La directory di installazione di default è <Program Files>\IBM\VisualAge per Java. In Windows 2000, per default, l'installazione in <ProgramFiles> può essere eseguita solo da utenti Administrator e Standard (Power). Utenti Regular (Restricted) non possono accedere in scrittura a tale ubicazione.

A causa del design corrente di VisualAge per Java, se il prodotto viene installato in questa ubicazione e deve essere utilizzato da un utente Regular (Restricted), è necessario modificare le impostazioni di sicurezza nella directory IBM o IBM\VisualAge per Java sotto <ProgramFiles> in modo da consentire l'accesso in scrittura a utenti regular. Errori in queste operazioni potrebbero provocare malfunzionamenti durante l'avvio dell'IDE o durante l'utilizzo di alcuni strumenti di VisualAge per Java all'interno dell'IDE.

L'elenco server per AS/400 Enterprise Toolkit è ora memorizzato come "<ProgramFiles>\IBM\shared files\fvdctcp.txt". Per default, questa ubicazione è protetta e gli utenti Regular non possono accedervi in scrittura. Se un utente privo di autorizzazione prova a creare o aggiornare l'elenco server mediante uno dei pulsanti dell'elenco server Aggiungi/Modifica delle SmartGuide AS/400, l'aggiornamento o la creazione del file non riuscirà e produrrà un errore i/e nella codifica Java che potrebbe essere visualizzato nella registrazione o nella console.

Il responsabile di sistema deve determinare se assegnare all'utente regular l'accesso in scrittura su questa ubicazione oppure se conservare la protezione e caricare il file manualmente, in modo da impedire ad utenti non autorizzati l'aggiornamento del file.

B.2.6 Installazione di IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9 

Se VisualAge per Java è stato installato dal CD del prodotto, è necessario eseguire install.exe dalla directory IBM Developer Kit per installare IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9. Questa directory si trova sul CD Funzioni aggiuntive. Se si dispone di una versione elettronica di VisualAge per Java, tale directory è ubicata nella propria directory temporanea (dove sono state estratte le parti), ma non è necessario eseguire install.exe, poichè il programma di installazione viene avviato automaticamente dopo averlo spacchettato dall'archivio IBM Developer Kit scaricato. 

Per informazioni dettagliate su IBM Developer Kit, fare riferimento al file README nella directory IBM Developer Kit.

B.3.0 Migrazione da una precedente versione di VisualAge per Java  

Per informazioni sulla migrazione generale e di componenti specifici prima di iniziare il processo di migrazione, fare riferimento alla Parte D e alla Parte E.

L'aggiornamento VisualAge per Java, Versione 4.0 eseguirà aggiornamenti del magazzino durante l'installazione per portare le librerie di classe del sistema presenti nel magazzino al livello di rilascio corretto. Ciò richiede che il magazzino sia disponibile all'accesso in lettura-scrittura durante questo aggiornamento. Nessuna codifica utente verrà modificata durante questa operazione.

Se si sta migrando da una precedente versione di VisualAge per Java, Edizione Enterprise, si opera in un ambiente autonomo (anzichè in un ambiente team) e si continuerà a operare in ambiente autonomo, seguire le istruzioni sulla migrazione relative alla Edizione Professional, contenute nella Parte A di questo documento.

Nota: Quando si sta passando da VisualAge per Java, Versione 3.5 o Versione 3.5.3 alla Versione 4.0, il processo di installazione potrebbe sembrare bloccato. Ciò si verifica poiché la funzione "DoCosting" (che confronta i file delle versioni 3.5 con i file delle versioni 4.0) può impiegare fino a tre minuti per l'esecuzione del confronto, provocando un sensibile rallentamento del processo di installazione.

Se si sta migrando da un ambiente team o verso un ambiente team, tenere presente quanto riportato di seguito prima di iniziare il processo di migrazione.

I passi da seguire durante la migrazione dipendono dalla situazione specifica e dalle risposte alle domande precedenti.

Il seguente scenario di migrazione è uno dei più complicati. In esso, si hanno più magazzini condivisi e N sviluppatori con magazzini locali Versione 3.5 o 3.5.3. Si desidera utilizzare il nuovo magazzino Versione 4.0 ma anche conservare l'utilizzo di tutti i dati contenuti nei vecchi magazzini condivisi. 

Nota: Questo scenario interessa i magazzini locali di Versione 3.5 o di Versione 3.5.3 (Java 2), non i magazzini locali JDK 1.1.x. Se si desidera importare informazioni di magazzini locali JDK 1.1.x nel proprio magazzino Versione 4.0, seguire le istruzioni riportate nella sezione 3.2 della Parte A. 

  1. Aggiornare EMSRV alla Versione 7.1. Il responsabile team deve installare EMSRV, Versione 7.1. Per istruzioni sull'esecuzione di questa operazione, fare riferimento alla sezione 2 della Parte C. 
  2. Creare copie di backup dei propri dati utente.
    1. Effettuare la versione dei progetti e dei pacchetti. E' possibile importare nel magazzino VisualAge per Java, Versione 4.0 solo i progetti e i pacchetti di cui è stata effettuata una versione. Per istruzioni sulla creazione di versioni, fare riferimento all'aiuto in linea di VisualAge per Java.
    2. Salvare il magazzino in una nuova ubicazione esterna alla struttura di directory di VisualAge per Java. Il percorso e il nome file del magazzino è x:\IBMVJava\ide\repository\ivj.dat, dove x:\IBMVJava indica la directory di installazione di VisualAge per Java. 
      Nota: Se si sta migrando dalla Versione 3.5 o 3.5.3, il magazzino comprende anche versioni delle copie dei propri file di risorse di progetto, ubicate nella directory: x:\IBMVJava\ide\repository\ivj.dat.pr. E' necessario salvare una copia della directory ivj.dat.pr al di fuori della struttura delle directory di VisualAge per Java.
  3. Il responsabile team esegue una completa installazione di VisualAge per Java, Versione 4.0, compreso un magazzino locale. Quindi, il responsabile esporta l'intero contenuto del magazzino locale in tutti i magazzini condivisi. Per dettagli sull'esecuzione di questa attività, fare riferimento alla Parte B, sezione 3.1.
  4. Tutti gli utenti della Versione 3.5 o 3.5.3 installano localmente la Versione 4.0, che aggiornerà automaticamente N magazzini locali.

A questo punto il processo di migrazione è completato e gli utenti possono passare da un magazzini locale a un magazzino condiviso e viceversa, a seconda delle necessità. Nota: Se si sta migrando da un ambiente team a un ambiente locale, è necessario esportare manualmente i propri progetti dal vecchio magazzino condiviso a quello locale. Allo stesso modo, se si disponeva di un magazzino locale, sarà necessario importare qualsiasi progetto che si desidera utilizzare dal vecchio magazzino locale al nuovo magazzino locale della Versione 4.0.

B.3.1 Migrazione di un magazzino condiviso da una precedente versione di VisualAge per Java

Prima di poter eseguire i seguenti passi è necessario effettuare l'aggiornamento a EMSRV 7.1. Istruzioni su come eseguire questa attività sono reperibili nella sezione C.3.1  

E' possibile aggiornare il proprio magazzino condiviso Versione 2.0 o 3.0x (su base JDK 1.1) o 3.0x, Early Adopters o 3.5 (su base JDK 1.2) per utilizzarlo con VisualAge per Java, Versione 4.0. Nei passi seguenti, il responsabile team esegue una completa installazione di VisualAge per Java, Versione 4.0 utilizzando un magazzino locale. Quindi, il responsabile esporta l'intero contenuto del magazzino locale in tutti i magazzini condivisi.

Per aggiornare un magazzino esistente sul server in modo da utilizzarlo con VisualAge per Java, Versione 4.0:

  1. Installare VisualAge per Java, Versione 4.0 come installazione completa con un magazzino locale. Fare riferimento alla sezione 2.0 nella Parte B per istruzioni su come eseguire questa attività.
  2. Avviare l'IDE della Versione 4.0. Si verrà collegati al magazzino locale.
  3. Nel Workbench, selezionare File > Esporta, quindi selezionare il pulsante a selezione ciclica Magazzino e fare clic su Avanti. Selezionare Magazzino condiviso con server EMSRV. Immettere l'indirizzo IP o il nome host del server nel campo Indirizzo server magazzino condiviso con EMSRV.
  4. Fare clic su Sfoglia per localizzare il magazzino condiviso oppure immettere il percorso e il nome file nel campo Nome magazzino.
  5. SelezionareProgetti. Fare clic su Dettagli per visualizzare un elenco di versioni di progetti che è possibile esportare dal magazzino di origine. 
  6. Selezionare tutte le edizioni di progetto ed esportarle.
  7. Fare clic su Fine.

Tutti i progetti vengono copiati nel proprio magazzino condiviso. Vengono esportati anche i file delle risorse di progetto. Se il magazzino in cui si sta esportando è denominato sample.dat, le risorse di progetto vengono esportate in una cartella denominata sample.dat.pr.

B.4.0 Limitazioni note e problemi

Fare anche riferimento al README (ubicato nella directory README del CD) per informazioni su limitazioni e problemi noti dell'ultima ora. 

B.4.1 Problemi noti e limitazioni di installazione  

Di seguito è riportato un elenco di informazioni che è opportuno tener presente durante l'installazione di VisualAge per Java.

B.4.1.1 Limitazioni del disco

B.4.1.2 Autorizzazione utente

B.4.1.3 Considerazioni TCP/IP

B.4.1.4 Estensione shell (Windows NT)

Se viene visualizzato un messaggio indicante che il programma di installazione ha rilevato un'estensione shell per Windows NT, l'installazione non potrà procedere. Sarà pertanto necessario effettuare i seguenti passi:

  1. Assicurarsi di avere a disposizione un disco di ripristino. Le istruzioni per la creazione di tale disco sono disponibili nella documentazione della guida di Windows.
  2. Immettere regedit.exe da un prompt dei comandi.
  3. Nell'Editor di registro, espandere la chiave
    \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  4. Selezionare il nome della shell nelle coppie nome/dati relative alla chiave sopra riportata. Importante: Prendere nota dei dati resgistrati per questo nome, poiché saranno necessari dopo l'installazione di IBM VisualAge per Java.
  5. Selezionare Edita > Modifica dalla barra dei menu per la coppi nome/dati della shell.
  6. Impostare il valore per il nome shell su Explorer.exe. Fare clic su OK.
  7. Selezionare Registro > Esci dalla barra dei menu.
  8. Riavviare e completare l'installazione di IBM VisualAge per Java.
  9. Una volta completata l'installazione, ripristinare la voce di registro precedente come segue:
    a. Immettere regedit.exe da una richiesta comandi.
    b. Nell'Editor di registro, espandere la chiave \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    c. Selezionare il nome della shell nelle coppie nome/dati della chiave riportata sopra.
    d. Selezionare Edita > Modifica dalla barra dei menu per la coppia nome/dati della shell.
    e. Ripristinare il valore del nome della shell sul valore registrato nel Passo 4. Fare clic su OK.
    f. Selezionare Registro > Esci dalla barra dei menu.

B.4.1.5 Ripristino da un'installazione non riuscita

Se l'installazione non riesce, è necessario rimuovere tutti i file della Versione 4.0 che sono stati installati. Se la directory in cui si desidera installare VisualAge per Java è vuota, il processo di installazione viene riportato indietro e ogni file installato viene rimosso. Se si desidera, è possibile cancellare la directory vuota, ma ciò non è necessario. Tuttavia, se la directory contiene file, è necessario avviare nuovamente il processo di installazione. Questo verrà aperto in modalità di manutenzione ed è necessario selezionare l'eliminazione dell'installazione parziale della Versione 4.0 prima di installare di nuovo il prodotto.

Sarà anche necessario cancellare la voce di registro:

\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge per Java per Windows

e seguire le istruzioni qui riportate:

  1. Assicurarsi di avere a disposizione un disco di ripristino. Le istruzioni per la creazione di tale disco sono disponibili nella documentazione della guida di Windows.
  2. Immettere regedit.exe da un prompt dei comandi.
  3. Nell'Editor di registro, espandere e selezionare la chiave
    \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java for Windows\4.0
  4. Selezionare Edita > Cancella dalla barra dei menu per questa chiave.
  5. Selezionare Sì quando viene visualizzata la richiesta di conferma della cancellazione della chiave.
  6. Selezionare Registro > Esci dalla barra menu.

Se qualsiasi file NetQuestion è stato installato prima del malfunzionamento dell'installazione, sarà necessario cancellarlo.

  1. Aprire un nuovo prompt di comandi. Controllare se sono stati installati file NetQuestion digitando quanto segue nel prompt di comandi appena aperto: set imninstsrv. Questo comando fornirà l'ubicazione in cui è installato NetQuestion. Ad esempio,

    IMNINSTSRV=C:\imnnq_nt

    L'ubicazione della directory NetQuestion potrebbe essere diversa, in base all'unità su cui si installa VisualAge per Java e al sistema operativo che si sta utilizzando. Se la variabile è impostata (cioè se si dispone di un'ubicazione in cui è installato NetQuestion), procedere al passo 2. 

    Se si riceve un messaggio di errore del tipo "Variabile di ambiente imninstsrv non definita", nessun file NetQuestion è stato installato oppure l'installazione di NetQuestion non è stata completata correttamente. Se ciò accade, selezionare Start > Trova > File o cartelle e ricercare il seguente file sul sistema: vahelp.cfg. Se tale file viene localizzato in una qualsiasi directory il cui nome inizia con "imnnq" (ad esempio, imnnq_NT o imnnq_98), cancellarlo. Non è necessario eseguire i passi 2 e 3. 

  2. Andare alla directory NetQuestion (riportata nelle informazioni che seguono IMNINSTSRV=)
  3. Digitare vahcfg remove /p vj32

In questo modo, tutti i file NetQuestion installati da VisualAge per Java vengono rimossi. Ciò non influenzerà i file NetQuestion installati da altri prodotti (ad esempio, DB2).

Se non è ancora stato fatto, eseguire il backup del magazzino e dei file di risorse. Fare riferimento alla Parte B, sezione 3.0 per informazioni sull'esecuzione di questa attività. 

Dopo aver eseguito tutti i passi, riavviare e reinstallare il prodotto. Se l'aiuto non funziona dopo aver re-installato VisualAge per Java, fare riferimento alla guida alla risoluzione dei problemi. La Guida alla risoluzione dei problemi (trshoot.htm) si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Dopo aver installato VisualAge per Java, sarà reperibile anche in X:\IBMVJava, dove X:\IBMVJava indica la directory di installazione di VisualAge per Java.

B.4.1.6 CICS Transaction Gateway

Se sulla macchina è installata una versione di CICS Transaction Gateway quando si installa VisualAge per Java, VisualAge utilizzerà questa versione invece di installarne una propria.

B.4.1.7 Errori del programma di installazione Windows

Di seguito è riportato un elenco degli errori di Windows Installer da tenere presente durante l'installazione.

Errore 1603 (solo Windows NT 4.0)

Se si riceve il messaggio di errore 1603 mentre si sta installando VisualAge per Java, significa che l'inizializzazione di Windows Installer non è riuscita e l'installazione non può procedere. 

Alcuni prodotti (come VisualCafe Symantec) installano automaticamente un file denominato sfc.dll quando vengono installati su qualsiasi piattaforma Windows. Questo file viene utilizzato solo su Windows 2000, richiamato da Windows Installer per il processo di protezione. 

Se un file con questo nome è ubicato sul PATH di Windows NT 4.0, Windows Installer tenterà di caricarlo, anche se sfc.dll non è applicabile a Windows 2000. In seguito a ciò, Windows Installer non riuscirà a funzionare. 

Per evitare questo problema:

  1. Selezionare Start > Trova > File o cartelle e ricercare il file sfc.dll sul proprio sistema.
  2. Ridenominare temporaneamente il file sfc.dll (la versione che si trova sul PATH di Windows NT 4.0) in sfc.old.
  3. Installare VisualAge per Java.
  4. Dopo aver installato VisualAge per Java, ridenominare sfc.old in sfc.dll.

Errore Fatal LoadLibrary()

L'errore Fatal LoadLibrary() si verifica quando uno o più kernel di installazione di VisualAge per Java (IKernels) non sono stati registrati correttamente da Windows Installer. Per risolvere il problema, è necessario cancellare la directory di InstallShield in cui sono ubicati i file IKernal e reinstallare VisualAge per Java seguendo questi passi:

  1. Se necessario, uscire dall'installazione.
  2. Cancellare la directory: x:\Program Files\Common Files\InstallShield, dove x indica l'unità su cui l'utente ha tentato di installare VisualAge per Java.
  3. Reinstallare il prodotto. 

Errore 1631 o Errore interno 2755 (solo Windows NT 4.0)

Se si installa VisualAge per Java su Windows NT 4.0, si potrebbe ricevere uno dei seguenti messaggi di errore:

Se si ricevono questi messaggi di errore, le chiavi di registro potrebbero avere valori nulli. Quando si avvia l'installazione di VisualAge per Java, il file userenv.dll proverà ad analizzare diverse chiavi di registro e, se qualcuna di queste ha valori nulli, l'installazione non riuscirà e verrà visualizzato uno dei precedenti messaggi di errore.

Per risolvere questo problema, rimuovere le variabili di ambiente con valori nulli oppure modificarle (cambiare il valore nullo in un valore valido) prima di installare VisualAge per Java. Dopo aver installato VisualAge per Java, è possibile riportarle ai valori originali.

Attenzione: Procedere alla rimozione o alla modifica delle variabili nulle con molta attenzione. Considerare qualsiasi impatto potenziale che potrebbe verificarsi prima di procedere.

Errori interni 2381, 1303, 1310, 1313 (solo Windows NT)

Se si sta provando ad installare VisualAge per Java e sono effettive una o tutte le seguenti condizioni:

si potrebbe ricevere uno o più messaggi di errore simili ai seguenti:

Questo problema risulta essersi verificato quando sono presenti solo autorizzazioni per la lettura sulle seguenti cartelle:

\Program Files\IBM\VisualAge for Java
\WinNT\Installer

Per risolvere il problema, accertarsi di disporre delle autorizzazioni necessarie per le proprie unità o directory. A tale scopo, seguire questi passi:

  1. In Windows Explorer, selezionare l'unità o la directory desiderata.
  2. Fare clic con il tastino destro del mouse sulla cartella e selezionare Proprietà dal menu a discesa.
  3. Selezionare il separatore Protezione. Fare clic su Autorizzazioni.
  4. Selezionare Tutti. Dal menu a discesa Tipo di accesso, selezionare Accesso completo.
  5. Selezionare la casella di selezione Sostituire autorizzazioni su sottodirectory.
  6. Fare clic su OK.
  7. Fare clic su Sì quando viene richiesto di confermare la sostituzione delle autorizzazioni su tutte le sottodirectory.
  8. Fare clic su OK.
  9. Installare VisualAge per Java.

Errore interno 2735 Avvio del motore

Se si riceve l'errore 2735, risolverlo eseguendo questi passi:

  1. Ricercare i seguenti file nella directory di sistema 32 Windows:
  2. Ridenominare shd401lc.dll come shd401lc.old.
  3. Ridenominare shdoclc.dll come shdoclc.old.
  4. Selezionare Start > Esegui per aprire la finestra di dialogo Esegui. Eseguire i seguenti comandi per deregistrare i file .dll. 
  5. Registrare queste dll eseguendo i comandi riportati di seguito dalla finestra di dialogo Esegui:
  6. Installare VisualAge per Java.

Errore 1606/Errore interno 2707

Se si riceve il seguente messaggio di errore, il valore del file di registro degli strumenti di gestione comuni potrebbe non essere corretto:

Errore 1606. Impossibile accedere all'ubicazione di rete \Profiles\AllUsers\StartMenu\Programs\Administrative Tools\.
Errore interno 2707. INSTALLDIR.

E' necessario editare il valore del file di registro degli strumenti di gestione comuni prima di poter installare VisualAge per Java. A tale scopo, seguire questi passi:

  1. Richiamare regedit.exe da una richiesta comandi.
  2. Espandere e selezionare la chiave
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folder
  3. Selezionare Strumenti di gestione comuni.
  4. Selezionare Edita > Modifica.
  5. Nel campo Dati di valore, immettere: %SystemRoot%\Profiles\AllUsers\StartMenu\Programs\Administrative Tools
  6. Fare clic su OK.
  7. Selezionare Registro > Esci dalla barra menu.
  8. Installare VisualAge per Java.

B.4.2 Problemi noti e limitazioni di disinstallazione 

Di seguito è riportato un elenco delle voci da tener presente durante la disinstallazione.

B.4.2.1 Spazio su disco

Sull'unità del sistema Windows sono necessari almeno 2MB di spazio libero; inoltre, è necessario che le variabili di ambiente TEMP o TMP siano indirizzate verso una directory temporanea valida con almeno 5MB di spazio libero.

B.4.2.2 Disinstallazione di Distributed Debugger

Se Distributed Debugger è stato installato come parte dell'installazione di VisualAge per Java, è necessario disinstallare VisualAge per Java PRIMA di disinstallare Distributed Debugger. Dopo aver disinstallato VisualAge per Java, è possibile disinstallare Distributed Debugger dalla directory di installazione del debugger eseguendo il programma di disinstallazione.

Se è stato disinstallato VisualAge per Java e non è possibile disinstallare Distributed Debugger, è necessario cancellare la chiave di registro:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java

e provare nuovamente a disinstallare il debugger. NON effettuare questi passi se si sta utilizzando Distributed Debugger con altri prodotti, altrimenti non sarà possibile utilizzare il debugger dopo aver cancellato la chiave di registro.

Seguire questi passi:

  1. Immettere regedit.exe da un prompt dei comandi.
  2. Nell'Editor di registro, espandere e selezionare la chiave
    HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
  3. Selezionare Edita > Cancella dalla barra dei menu per questa chiave.
  4. Selezionare Sì quando viene visualizzata la richiesta di conferma della cancellazione della chiave.
  5. Selezionare Registro > Esci dalla barra menu.

Allo stesso modo, impostare il valore della seguente chiave di registro su 1:

HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount

B.4.2.3 Variabili di ambiente (Windows 98)

Quando si disinstalla VisualAge per Java su Windows 98, è possibile che alcune voci di ambiente rimangano nel file autoexec.bat. Di solito tali voci non causano problemi, a meno che non si eseguano frequenti operazioni di disinstallazione e reinstallazione del prodotto. E' possibile che siano presenti istruzioni di percorso in conflitto che impediscono il funzionamento dell'aiuto in linea oppure che lo spazio di percorso non sia sufficiente, impedendo la corretta reinstallazione del prodotto.

Per risolvere tali problemi:

  1. Effettuare una copia di backup del file autoexec.bat.
  2. Verificare l'eventuale presenza di un altro programma che richiede il motore di ricerca HTML (come DB2) sul sistema eseguendo i passi riportati di seguito:
    a) Disinstallare VisualAge per Java e riavviare il sistema.
    b) Immettere regedit.exe da una richiesta comandi e, nell'Editor di registro, espandere la struttura di HKEY_LOCAL_MACHINE\SOFTWARE\. Se in questa struttura è presente una directory IBM, espanderla per vedere se contiene una directory NetQuestion. In caso positivo, è probabile che si stia utilizzando il motore di ricerca con un altro prodotto IBM.
  3. Se non si sta utilizzando il motore di ricerca HTML per un altro prodotto, eliminare qualsiasi immissione IMN o IMQ dal proprio file autoexec.bat prima di reinstallare VisualAge per Java.
  4. Se, invece, si sta utilizzando il motore di ricerca HTML per un altro prodotto, cancellare ogni duplicato di tali immissioni dal file autoexec.bat:

    IMNINST
    IMNINSTSRV
    IMNNQ
    IMNNQ_95
    IMQCONFIGCL
    IMQCONFIGSRV
    Cancellare anche voci duplicate della riga IF EXIST X:\IMNNQ_95\IMNENV.BAT CALL IMNEV.BAT
  5. Assicurarsi di non eliminare le voci originali quando si eliminano le copie. Se non si è certi di quali siano le voci originali, verificare l'ubicazione in cui il sistema considera installato NetQuestion. Seguire questi passi:
    1. Immettere regedit.exe da una richiesta comandi.
    2. Nell'Editor di registro, espandere la chiave \\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\NetQuestion\Installation Directory
    3. Il valore di directory interno della chiave mostra il percorso di installazione di NetQuestion. Per il corretto funzionamento di NetQuestion, alcune variabili di ambiente contengono questa directory come parte del proprio valore.

      Se si rileva una o più delle variabili di ambiente riportate in precedenza che include una directory diversa da quella trovata nel registro come parte del proprio valore, è necessario cancellarla.

B.4.2.4 Disinstallazione di NetQuestion

Quando si sta disinstallando VisualAge per Java, NetQuestion potrebbe non essere disinstallato. Si possono verificare dei problemi se NetQuestion non viene disinstallato quando si tenta di installare nuovamente il prodotto. 

Per eliminare i file NetQuestion installati da VisualAge per Java, seguire questi passi. Ciò non influenzerà i file NetQuestion installati da altri prodotti (ad esempio, DB2).

  1. Per trovare la directory NetQuestion, digitare quanto segue in un prompt di comandi: set imninstsrv. Questo comando fornirà l'ubicazione in cui è installato NetQuestion. Ad esempio,

    IMNINSTSRV=C:\imnnq_nt

    L'ubicazione della directory NetQuestion potrebbe essere diversa, in base all'unità su cui è installato VisualAge per Java e al sistema operativo che si sta utilizzando. Se si riceve un messaggio di errore del tipo "Variabile di ambiente imninstsrv non definita", tutti i file NetQuestion sono stati disinstallati.

  2. Andare alla directory NetQuestion (riportata nelle informazioni che seguono IMNINSTSRV=)
  3. Digitare vahcfg remove /p vj32

In questo modo, tutti i file NetQuestion installati da VisualAge per Java vengono rimossi. 

Se l'aiuto non funziona dopo aver re-installato VisualAge per Java, fare riferimento alla guida alla risoluzione dei problemi. La Guida alla risoluzione dei problemi (trshoot.htm) si trova nel CD del prodotto VisualAge per Java, Edizione Professional e nel CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Dopo aver installato VisualAge per Java, sarà reperibile anche in X:\IBMVJava, dove X:\IBMVJava indica la directory di installazione di VisualAge per Java.

Parte C: EMSRV

Per informazioni sull'installazione del client VisualAge per Java, fare riferimento alla Parte B della presente guida. Per informazioni sull'impostazione e la gestione del server, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs del CD Funzioni aggiuntive oppure nella propria directory temporanea (dove sono state estratte le parti) se si dispone di una versione elettronica di VisualAge per Java.

Se si pianifica di operare in un ambiente team con l'Edizione Enterprise di VisualAge per Java, è necessario utilizzare EMSRV, Versione 7.1.

Tutti i file EMSRV sono ubicati nel CD Funzioni aggiuntive.

C.1.0 Prerequisiti

Prima di installare EMSRV, fare anche riferimento alla sezione "Problemi noti e limitazioni" alla fine della Parte C.

C.1.1 Piattaforme supportate

Il server EMSRV è supportato per le seguenti piattaforme di sistemi operativi:

* Nota: HP-UX è supportato esclusivamente su macchine stazioni di lavoro di classe 700. Ciò è stato verificato su una macchina HP-UX 9000/715/60 e su una macchina HP-UX 9000/782/200+. Poiché le macchine di classe 800 (server) hanno un'architettura diversa e richiedono binari diversi, su tale tipo di macchine EMSRV non è supportato.

+ Per informazioni su come ottenere la correzione, fare riferimento alla sezione C.1.4.

IBM non supporta più EMSRV su Netware 4.11 o Netware 5.0, ma è possibile eseguire EMSRV su tale piattaforma se CLIBAUX.NLM viene caricato prima di EMSRV.NLM. CLIBAUX.NLM è incluso in Novell's Support Pack 8a ma è anche disponibile separatamente da Novell nel file CLIBAUX1.EXE reperibile alla seguente ubicazione:

http://support.novell.com/cgi-bin/search/download?/pub/updates/nw/nw42/clibaux1.exe

Ritiro del supporto per hardware SMP

** NOTA IMPORTANTE: L'esecuzione di qualsiasi rilascio di EMSRV per Windows NT/2000 su una macchina con più processori potrebbe provocare il danneggiamento dei magazzini.

EMSRV non è più supportato su server Windows NT/2000 che eseguono su hardware SMP (macchine con più processori). La scelta di eliminare il supporto per hardware SMP è dovuta alla frequenza dei rapporti concernenti il danneggiamento di magazzini con server Windows e hardware SMP. EMSRV continua a supportare l'hardware SMP per tutti gli altri sistemi operativi.

IBM NON SI ASSUME ALCUNA RESPONSABILITA' DEI DANNI CHE POTREBBERO RISULTARE DALL'USO DI EMSRV SU UN SERVER WINDOWS NT/2000 ESEGUITO SU HARDWARE SMP, INCLUSO MA NON LIMITATO, A DANNI SUBITI DALL'UTENTE RICONDUCIBILI A TERZI. IN NESSUN CASO LA IBM, I SUOI FORNITORI, AGENTI E DIPENDENTI SARANNO DA RITENERSI RESPONSABILI PER DANNI INDIRETTI, SPECIALI, ESEMPLARI O CONSEQUENZIALI DERIVANTI DALL'USO DI EMSRV SU UN SERVER WINDOWS NT/2000 IN ESECUZIONE SU HARDWARE SMP.

Se si desidera utilizzare EMSRV su un server in esecuzione su hardware SMP, è necessario utilizzare il parametro -mp all'avvio di EMSRV. In questo modo verrà evitato il controllo di hardware SMP. In questo modo, EMSRV verrà eseguito su una piattaforma non supportata e l'utente si assumerà la piena responsabilità (IBM NON SI ASSUME ALCUNA RESPONSABILITA') dell'eventuale conseguente danneggiamento dei magazzini.

EMSRV non sfrutta le capacità di processori extra, dato che EMSRV rappresenta un processo dipendente da immissioni/emissioni e non da processori. Conseguentemente, le prestazioni di EMSRV non sono influenzate dal numero di processori presenti sul server.

C.1.2 TCP/IP

TCP/IP deve essere installato e configurato sul server.

C.1.3 Correzioni Novell necessarie per eseguire EMSRV

Ottenere ed applicare l'elenco di correzioni minime di NetWare. Tali file di correzioni sono disponibili su http://support.novell.com/misc/patlst.htm. Selezionare ed applicare le correzioni adatte per la versione di NetWare che si sta utilizzando.

C.1.4 Correzione necessaria per eseguire EMSRV su Solaris

Nell'implementazione PAM Solaris, Versione 2.6 è presente un errore che impedisce il corretto funzionamento di EMSRV. E' necessario applicare la correzione 106257-05 se si sta utilizzando EMSRV su Solaris, Versione 2.6. La correzione è disponibile su:

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106257&zone_32=PAM

L'errore da correggere è:

4092227 pam_conv appdata_ptr member is not passed thru to conv() function as documented

La correzione non è richiesta se si sta lavorando con la Versione 7.0 di Solaris.

C.1.5 Sistemi di file supportati

EMSRV è stato controllato e certificato con i seguenti sistemi di file:

NetWare

OS/2

Windows NT e Windows 2000

Solaris

HP-UX

AIX

Linux

EMSRV supporta solo sistemi di file allestiti localmente.

C.2.0 Installazione

Questa sezione contiene istruzioni per l'installazione del programma server del magazzino EMSRV e di un magazzino condiviso. Per istruzioni sull'avvio del server, fare riferimento al file "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.

C.2.1 Installazione di EMSRV per Windows(R)

Impostazione di EMSRV per Windows
Prima di installare EMSRV su Windows, tenere presente quanto riportato di seguito relativamente ai tipi di file:

Installazione di EMSRV su Windows
Per installare il programma server del magazzino EMSRV e un magazzino condiviso su un server Windows NT o Windows 2000:

  1. Dalla directory TeamServer/Windows del CD Funzioni aggiuntive, eseguire setup.exe.
  2. Seguire le istruzioni visualizzate sullo schermo. Quando viene richiesto di selezionare una directory di installazione, selezionare una sottodirectory che faccia parte del PATH oppure creare una sottodirectory e aggiungerla al PATH. Si consiglia di effettuare il posizionamento in una ubicazione che disponga di molto spazio libero poiché il file emsrv.log verrà scritto nella sottodirectory selezionata.
  3. Estrarre quanto segue dal file ide.zip nella directory desiderata: 

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

Questa directory è il punto in cui si intende memorizzare i magazzini di codifica di origine condivisi. Quando si avvia il server in un secondo momento, l'utente specificherà questa sottodirectory come directory di lavoro EMSRV, utilizzando il parametro di avvio EMSRV -W quando si avvia il server.

EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. La directory ivj.dat.pr deve sempre essere copiata nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto.

E' possibile scegliere di ridenominare il file di magazzino, ad esempio in team1.dat. Se si ridenomina il magazzino dopo averlo copiato sul server, è necessario ridenominare allo stesso modo la directory delle risorse di progetto. Ad esempio, se si ridenomina il magazzino come team1.dat, modificare il nome della directory delle risorse di progetto come team1.dat.pr.

I membri del team dovranno specificare il nome file del magazzino al momento dell'installazione della codifica client VisualAge per Java. Inoltre, dovranno specificare il percorso sulla macchina del server.

  1. Se si desidera abilitare la verifica della parola d'ordine mediante l'utilizzo di un file passwd.dat, copiare questo file dalla directory TeamServer nella stessa directory in cui è stato copiato ivj.dat. Per ulteriori informazioni sui tipi di verifica parola d'ordine disponibili, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.
  2. Verificare che TCP/IP sia installato e collegato correttamente a un adattatore LAN. E' possibile verificare il collegamento utilizzando il comando ping (ad esempio, ping indirizzo IP/nome host) per comunicare con il server da una stazione di lavoro sulla LAN.
  3. Procedere con l'installazione di EMSRV nel registro Windows NT (facoltativo), autorizzare l'utente EMSRV ed avviare EMSRV. Questi argomenti sono illustrati nel file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese).
C.2.1.1 Installazione di EMSRV come servizio nel registro Windows

Se si preferisce avviare EMSRV come servizio invece che da un prompt dei comandi, è possibile installarlo nel registro Windows. In tal modo si beneficia di due vantaggi:

Suggerimento: Se EMSRV viene avviato come servizio, la directory di lavoro EMSRV di default è la directory Windows NT o Windows 2000 system32\. Si consiglia di modificare questo default utilizzando il parametro -W quando si installa EMSRV come servizio nel registro Windows NT o Windows 2000.

Importante: EMSRV non è più supportato su server Windows NT/2000 che eseguono su hardware SMP (macchine con più processori). La scelta di eliminare il supporto per hardware SMP è dovuta alla frequenza dei rapporti concernenti il danneggiamento di magazzini con server Windows e hardware SMP.  EMSRV continua a supportare l'hardware SMP per tutti gli altri sistemi operativi.

IBM NON SI ASSUME ALCUNA RESPONSABILITA' DEI DANNI CHE POTREBBERO RISULTARE DALL'USO DI EMSRV SU UN SERVER WINDOWS NT/2000 ESEGUITO SU HARDWARE SMP, INCLUSO MA NON LIMITATO, A DANNI SUBITI DALL'UTENTE RICONDUCIBILI A TERZI. IN NESSUN CASO LA IBM, I SUOI FORNITORI, AGENTI E DIPENDENTI SARANNO DA RITENERSI RESPONSABILI PER DANNI INDIRETTI, SPECIALI, ESEMPLARI O CONSEQUENZIALI DERIVANTI DALL'USO DI EMSRV SU UN SERVER WINDOWS NT/2000 IN ESECUZIONE SU HARDWARE SMP.

Se si desidera installare e avviare EMSRV come servizio Windows NT/2000 su hardware SMP, è necessario installare il servizio utilizzando il parametro -mp. In questo modo verrà evitato il controllo di hardware SMP. In questo modo, EMSRV verrà eseguito su una piattaforma non supportata e l'utente si assumerà la piena responsabilità (IBM NON SI ASSUME ALCUNA RESPONSABILITA') dell'eventuale conseguente danneggiamento dei magazzini.

Se non si installa il servizio utilizzando il parametro -mp, il servizio non verrà avviato e si riceverà il seguente messaggio di errore:

Impossibile avviare il servizio EMSRV su \\host
Errore 2140: Si è verificato un errore interno Windows NT.

Se si prova nuovamente ad installare EMSRV come servizio (ad esempio, per aggiungere il parametro -mp), il servizio verrà installato ma si riceverà il seguente errore:

File di messaggi emsrvmsg.dll, impossibile copiare in C:\WINNT\System32\emsrvmsg.dll

--- Errore OS 1224: L'operazione richiesta non può essere eseguita su un file con una sezione associata all'utente aperta. Accertarsi che la DLL si trovi nella stessa directory di EMSRV.EXE.

E' possibile ignorare questo messaggio di errore poiché la DLL sarà già stata installata durante la precedente installazione del servizio.

Per installare EMSRV come servizio:

  1. Da una riga comandi, modificare la directory nella directory in cui è installato il programma eseguibile EMSRV.
  2. Immettere il comando emsrv -install [parameter2] [parameter3] ...  Il primo parametro deve essere -install; gli atri sono rappresentati dai parametri di avvio EMSRV scelti dall'utente per il proprio ambiente.

    Di seguito è riportato un esempio di questo comando:

    emsrv -install -u joe -p donttell -W j:\sharedrep -rn

    In questo esempio EMSRV viene installato come servizio nel registro Windows, con joe come nome utente EMSRV e donttell come parola d'ordine di joe. Per default, la directory di lavoro di EMSRV sarà j:\sharedrep e la convalida della parola d'ordine nativa sarà confermata.

    Un messaggio conferma che EMSRV è stato installato.
  3. I passi a/b sono leggermente differenti per Windows NT e Windows 2000.
    a) Dal Pannello di controllo Windows NT, fare doppio clic su Servizi. Verrà visualizzata la finestra di dialogo Servizi. Selezionare EMSRV dall'elenco dei servizi. 
    b) Dal Pannello di controllo Windows 2000, fare doppio clic su Strumenti di gestione. Fare doppio clic su Servizi. Fare doppio clic su EMSRV.
    E' possibile avviare manualmente EMSRV da questo pannello. EMSRV ora è installato come servizio del registro mentre le DLL necessarie sono state copiate nella directory del sistema.
  4. Nella casella di testo Parametri di avvio, immettere i parametri di avvio di EMSRV che si desidera utilizzare. Se si sta specificando la directory di lavoro per EMSRV, immettere una barra retroversa extra per ogni barra retroversa presente nel percorso. Di seguito è riportato un esempio:

    -u emsrvacc -p secret -W d:\\javateam
  5. Fare clic su Start. Verrà visualizzato un messaggio che informa dell'avvio di EMSRV.

Per ulteriori informazioni sull'avvio di EMSRV, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.

Per default, quando viene avviato EMSRV vengono utilizzati i parametri forniti. E' anche possibile sovrascrivere o aggiungere altri parametri a quelli esistenti se EMSRV viene avviato manualmente dall'icona Servizi del pannello di controllo di Windows.

C.2.2 Installazione di EMSRV per NetWare

Impostazione di EMSRV per Netware
Prima di installare EMSRV su Netware, tenere presente le seguenti limitazioni:

Installazione di EMSRV su Netware
Per installare il programma del server di magazzino EMSRV e un magazzino condiviso su NetWare:

  1. Dalla directory TeamServer\Netware, copiare i seguenti file di programma nella directory SYS:\SYSTEM del server:
  2. Estrarre quanto segue dal file ide.zip nella directory desiderata sul server:

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

Quando si avvia il server in un secondo momento, l'utente specificherà questa sottodirectory come directory di lavoro EMSRV, utilizzando il parametro di avvio EMSRV -W. EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. La directory ivj.dat.pr deve sempre essere copiata nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto.

E' possibile scegliere di ridenominare il file di magazzino, ad esempio in team1.dat. Se si ridenomina il magazzino dopo averlo copiato sul server, è necessario ridenominare allo stesso modo la directory delle risorse di progetto. Ad esempio, se si ridenomina il magazzino come team1.dat, modificare il nome della directory delle risorse di progetto come team1.dat.pr.

I membri del team dovranno specificare il nome file di magazzino e l'ubicazione al momento dell'installazione della codifica client di VisualAge per Java.

  1. Copiare il file delle parole d'ordine di esempio, passwd.dat, dalla directory TeamServer nella stessa directory in cui è stato copiato ivj.dat. 
  2. Verificare che NetWare TCPIP.NLM sia caricato e collegato correttamente a un adattatore LAN. E' possibile verificare il collegamento uilizzando il comando ping (ad esempio, ping indirizzo IP/nome host) per comunicare con il prodotto da una stazione di lavoro su LAN.
  3. Per assicurare che i nomi host appariranno nell'emissione EMADMIN quando si esegue l'interrogazione di EMSRV, verificare che il resolver sia impostato correttamente per abilitare lookup DNS reverse. Assicurarsi anche che il file RESOLV.CFG (ubicato in sys:\etc) sia impostato in modo corretto. Di seguito è riportato un esempio di impostazione del file: 
    domain javadev.com
    nameserver 192.168.73.150
  4. Per istruzioni sull'avvio del prodotto, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.

C.2.3 Installazione di EMSRV per OS/2 Warp

Nota: OS/2 non è più supportato come piattaforma di sviluppo. Per dettagli, fare riferimento alla Parte E.

Impostazione di EMSRV per OS/2
Prima di installare EMSRV su OS/2, tenere presente quanto riportato di seguito:

Installazione di EMSRV su OS/2 
Per installare il programma del server di magazzino EMSRV e un magazzino condiviso su un server OS/2, seguire questi passi:

  1. Copiare i seguenti tre file dalla directory TeamServer alla directory desiderata sul computer OS/2:

    Sistemare questi file in una sottodirectory che faccia parte del proprio PATH oppure creare una sottodirectory ed aggiungerla al PATH. Si consiglia di sistemarli in una ubicazione che disponga di molto spazio libero poiché il file emsrv.log verrà scritto nella sottodirectory in cui vengono sistemati tali file.

  2. Estrarre quanto segue dal file ide.zip nella sottodirectory in cui sono stati sistemati i file copiati nel passo 1:

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

    Questa sottodirectory è il punto in cui si intende memorizzare i magazzini di codifica di origine condivisi. Quando si avvia il server in un secondo momento, l'utente specificherà questa sottodirectory come directory di lavoro EMSRV, utilizzando il parametro di avvio EMSRV -W.

    EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. La directory ivj.dat.pr deve sempre essere copiata nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto.

    E' possibile scegliere di ridenominare il file di magazzino, ad esempio in team1.dat. Se si ridenomina il magazzino dopo averlo copiato sul server, è necessario ridenominare allo stesso modo la directory delle risorse di progetto. Ad esempio, se si ridenomina il magazzino come team1.dat, modificare il nome della directory delle risorse di progetto come team1.dat.pr.

    I membri del team dovranno specificare il nome file del magazzino al momento dell'installazione della codifica client VisualAge per Java.

  3. Se si desidera abilitare la verifica della parola d'ordine mediante l'utilizzo di un file passwd.dat, copiare questo file dalla directory TeamServer nella stessa directory in cui è stato copiato ivj.dat. Per ulteriori informazioni sui tipi di verifica parola d'ordine disponibili, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.
  4. Verificare che TCP/IP sia installato e collegato correttamente a un adattatore LAN. E' possibile verificare il collegamento utilizzando il comando ping (ad esempio, ping indirizzo IP/nome host) per comunicare con il server da una stazione di lavoro sulla LAN.
  5. Per avviare il server, fare riferimento alle istruzioni per l'avvio di EMSRV su OS/2 contenute nel file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese).

C.2.4 Installazione di EMSRV per AIX

Impostazione di EMSRV per AIX
Prima di installare EMSRV su AIX, tenere presente le seguenti caratteristiche:

Installazione di EMSRV su AIX
Nei passi seguenti, "utente EMSRV" si riferisce all'utente che avvia il programma EMSRV.

E' necessario copiare i seguenti file dalla directory Teamserver alla propria macchina:

Sistemare questi file in una sottodirectory che faccia parte del proprio PATH oppure creare una sottodirectory ed aggiungerla al PATH. Si consiglia di sistemarli in una ubicazione che disponga di molto spazio libero poiché il file emsrv.log verrà scritto nella sottodirectory in cui vengono sistemati tali file.

Seguire i passi riportati di seguito per impostare EMSRV su una macchina AIX:

  1. L'utente EMSRV oppure il responsabile di sistema (root) riserva spazio su disco per la memorizzazione dei magazzini.
  2. Un magazzino iniziale può essere impostato copiando quanto segue dal file ide.zip nello spazio disco riservato nel passo 1.

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

    EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. La directory ivj.dat.pr deve sempre essere copiata nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto. Le directory devono avere bit rw e x (ricerca) impostati per l'utente EMSRV.

  3. Cambiare il proprietario del file nell'utente EMSRV o nel responsabile di sistema. Se si decide di disporre di più magazzini, eseguire copie di ivj.dat usando nomi diversi ma conservando lo stesso suffisso (.dat).Se si effettuano duplicati del magazzino, è necessario effettuare duplicati della directory ivj.dat.pr e modificare il nome in modo che corrisponda al magazzino a cui è associato. Ad esempio, se si effettua un duplicato denominato "team.dat", è necessario effettuare un duplicato della directory delle risorse di progetto denominata "team.dat.pr"
    L'utente EMSRV o il responsabile di sistema deve modificare la directory con quella in cui sono memorizzati i magazzini ed avviare il programma EMSRV utilizzando gli indicatori appropriati. Per ulteriori informazioni sugli indicatori EMSRV, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.
  4. L'utente EMSRV o il responsabile di sistema comunica ai membri del team l'ubicazione e il nome del magazzino del team. Queste informazioni sono necessarie quando i membri del team installano la codifica dei client.
  5. Per avviare il server, fare riferimento alle istruzioni contenute nel file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese).

Su piattaforme UNIX, per l'autenticazione degli utenti è necessario l'accesso root. EMSRV NON richiede di essere avviato dall'utente root per fare ciò. Tale operazione comprometterebbe la sicurezza poiché EMSRV avrebbe accesso completo a tutti i sistemi di file.

Invece, modificare il proprietario dell'eseguibile EMSRV in 'root' e impostare il bit SUID dell'eseguibile. Ciò può essere effettuato come segue:

chown root emsrv
chmod u+s emsrv

Quando EMSRV prova ad autenticare un utente, cambierà temporaneamente l'autorizzazione del processo EMSRV in esecuzione in modo che diventi l'autorizzazione del proprietario dell'eseguibile. Una volta completata l'autenticazione, l'autorizzazione del processo EMSRV in esecuzione tornerà ad essere quella dell'utente che ha avviato EMSRV. Questo avviene su una base per-processo (per-client), cioé mentre un client viene autenticato, solo il processo che server tale client ha il temporaneo accesso root.

L'accesso root per l'autenticazione è richiesto a prescindere da come, al momento, EMSRV implementa l'autenticazione. Le interfacce come PAM forniscono solo un'API comune per permettere alle applicazioni il supporto di più metodi di autenticazione; la configurazione specifica di ciascun metodo di autenticazione deve essere ancora corretta. 

C.2.5 EMSRV per HP-UX o Solaris

C.2.5.1 Impostazione di EMSRV per HP-UX o Solaris
Prima di installare EMSRV su Solaris o HP-UX, tenere presente quanto riportato di seguito:

Per Solaris

Per HP-UX 

C.2.5.2 Installazione di EMSRV per HP-UX o Solaris
Nei passi seguenti, "utente EMSRV" si riferisce all'utente che avvia il programma EMSRV.

E' necessario copiare i seguenti file dalla directory Teamserver alla propria macchina:

Per HP-UX:

Per Solaris:

Sistemare questi file in una sottodirectory che faccia parte del proprio PATH oppure creare una sottodirectory ed aggiungerla al PATH. Si consiglia di sistemarli in una ubicazione che disponga di molto spazio libero poiché il file emsrv.log verrà scritto nella sottodirectory in cui vengono sistemati tali file.

Seguire i passi riportati di seguito per impostare EMSRV su una macchina Solaris o HP-UX:

  1. L'utente EMSRV oppure il responsabile di sistema (root) riserva spazio su disco per la memorizzazione dei magazzini.
  2. Un magazzino iniziale può essere impostato copiando quanto segue dal file ide.zip nello spazio disco riservato nel passo 1.

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

    EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. ivj.dat.pr deve sempre essere copiato nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto. Le directory devono avere bit rw e x (ricerca) impostati per l'utente EMSRV.

  3. Cambiare il proprietario del file nell'utente EMSRV o nel responsabile di sistema. Se si decide di disporre di più magazzini, eseguire copie di ivj.dat usando nomi diversi ma conservando lo stesso suffisso (.dat).Se si effettuano duplicati del magazzino, è necessario effettuare duplicati della directory ivj.dat.pr e modificare il nome in modo che corrisponda al magazzino a cui è associato. Ad esempio, se si effettua un duplicato denominato "team.dat", è necessario effettuare un duplicato della directory delle risorse di progetto denominata "team.dat.pr"
    L'utente EMSRV o il responsabile di sistema deve modificare la directory con quella in cui sono memorizzati i magazzini ed avviare il programma EMSRV utilizzando gli indicatori appropriati. Per ulteriori informazioni sugli indicatori EMSRV, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.
  4. L'utente EMSRV o il responsabile di sistema comunica ai membri del team l'ubicazione e il nome del magazzino del team. Queste informazioni sono necessarie quando i membri del team installano la codifica dei client.
  5. Per avviare il server, fare riferimento alle istruzioni contenute nel file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese).

Su piattaforme UNIX, per l'autenticazione degli utenti è necessario l'accesso root. EMSRV NON richiede di essere avviato dall'utente root per fare ciò. Tale operazione comprometterebbe la sicurezza poiché EMSRV avrebbe accesso completo a tutti i sistemi di file.

Invece, modificare il proprietario dell'eseguibile EMSRV in 'root' e impostare il bit SUID dell'eseguibile. Ciò può essere effettuato come segue:

chown root emsrv
chmod u+s emsrv

Quando EMSRV prova ad autenticare un utente, cambierà temporaneamente l'autorizzazione del processo EMSRV in esecuzione in modo che diventi l'autorizzazione del proprietario dell'eseguibile. Una volta completata l'autenticazione, l'autorizzazione del processo EMSRV in esecuzione tornerà ad essere quella dell'utente che ha avviato EMSRV. Questo avviene su una base per-processo (per-client), cioé mentre un client viene autenticato, solo il processo che server tale client ha il temporaneo accesso root.

L'accesso root per l'autenticazione è richiesto a prescindere da come, al momento, EMSRV implementa l'autenticazione. Le interfacce come PAM forniscono solo un'API comune per permettere alle applicazioni il supporto di più metodi di autenticazione; la configurazione specifica di ciascun metodo di autenticazione deve essere ancora corretta. 

C.2.6 EMSRV per Linux

C.2.6.1 Impostazione di EMSRV per Linux
Prima di installare EMSRV su Linux, tenere presente le seguenti informazioni:

C.2.6.2 Installazione di EMSRV per Linux
Nei passi seguenti, "utente EMSRV" si riferisce all'utente che avvia il programma EMSRV.

E' necessario copiare i seguenti file dalla directory Teamserver alla propria macchina:

Sistemare questi file in una sottodirectory che faccia parte del proprio PATH oppure creare una sottodirectory ed aggiungerla al PATH. Si consiglia di sistemarli in una ubicazione che disponga di molto spazio libero poiché il file emsrv.log verrà scritto nella sottodirectory in cui vengono sistemati tali file.

Seguire i passi riportati di seguito per impostare EMSRV su una macchina Linux:

  1. L'utente EMSRV oppure il responsabile di sistema (root) riserva spazio su disco per la memorizzazione dei magazzini.
  2. Un magazzino iniziale può essere impostato copiando quanto segue dal file ide.zip nello spazio disco riservato nel passo 1.

    Il file ide.zip si trova nella directory ivj40\backup del CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti).

    EMSRV deve avere un permesso completo per la lettura, la scrittura e la ricerca nell'intera struttura delle directory in ivj.dat.pr. La directory ivj.dat.pr deve sempre essere copiata nella stessa directory di ivj.dat, diversamente non sarà possibile accedere alla risorse di progetto. Le directory devono avere bit rw e x (ricerca) impostati per l'utente EMSRV.

  3. Cambiare il proprietario del file nell'utente EMSRV o nel responsabile di sistema. Se si decide di disporre di più magazzini, eseguire copie di ivj.dat usando nomi diversi ma conservando lo stesso suffisso (.dat).Se si effettuano duplicati del magazzino, è necessario effettuare duplicati della directory ivj.dat.pr e modificare il nome in modo che corrisponda al magazzino a cui è associato. Ad esempio, se si effettua un duplicato denominato "team.dat", è necessario effettuare un duplicato della directory delle risorse di progetto denominata "team.dat.pr"
    L'utente EMSRV o il responsabile di sistema deve modificare la directory con quella in cui sono memorizzati i magazzini ed avviare il programma EMSRV utilizzando gli indicatori appropriati. Per ulteriori informazioni sugli indicatori EMSRV, fare riferimento al file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese), reperibile nella directory TeamServer\docs.
  4. L'utente EMSRV o il responsabile di sistema comunica ai membri del team l'ubicazione e il nome del magazzino del team. Queste informazioni sono necessarie quando i membri del team installano la codifica dei client.
  5. Per avviare il server, fare riferimento alle istruzioni contenute nel file di "Impostazione e gestione del server", emsrv71.htm (emsrv70.htm per tutte le lingue diverse dall'inglese).

Su piattaforme UNIX, per l'autenticazione degli utenti è necessario l'accesso root. EMSRV NON richiede di essere avviato dall'utente root per fare ciò. Tale operazione comprometterebbe la sicurezza poiché EMSRV avrebbe accesso completo a tutti i sistemi di file.

Invece, modificare il proprietario dell'eseguibile EMSRV in 'root' e impostare il bit SUID dell'eseguibile. Ciò può essere effettuato come segue:

chown root emsrv
chmod u+s emsrv

Quando EMSRV prova ad autenticare un utente, cambierà temporaneamente l'autorizzazione del processo EMSRV in esecuzione in modo che diventi l'autorizzazione del proprietario dell'eseguibile. Una volta completata l'autenticazione, l'autorizzazione del processo EMSRV in esecuzione tornerà ad essere quella dell'utente che ha avviato EMSRV. Questo avviene su una base per-processo (per-client), cioé mentre un client viene autenticato, solo il processo che server tale client ha il temporaneo accesso root.

L'accesso root per l'autenticazione è richiesto a prescindere da come, al momento, EMSRV implementa l'autenticazione. Le interfacce come PAM forniscono solo un'API comune per permettere alle applicazioni il supporto di più metodi di autenticazione; la configurazione specifica di ciascun metodo di autenticazione deve essere ancora corretta. 

C.3.0 Migrazione 

C.3.1 Migrazione dalla Versione 6.x o 7.0 di EMSRV alla Versione 7.1

Se la Versione 6.x o 7.0 di EMSRV è correntememnte installata e si desidera installare la Versione 7.1, è possibile disinstallare la versione 6.x/7.0 ed installare la successiva oppure conservare la vecchia versione ed installare EMSRV 7.1.

Per lavorare con VisualAge per Java, Versione 4.0, è necessario installare la Versione 7.1. 

Per passare da EMSRV, Versione 6.x/7.0 a EMSRV, Versione 7.1, seguire i passi riportati di seguito:

  1. Eseguire il backup del magazzino.
  2. Chiudere EMSRV 6.x/7.0.
  3. Installare EMSRV 7.1.
  4. Avviare EMSRV 7.1. 

EMSRV 7.1 è compatibile con EMSRV 6.x/7.0. Ad esempio, se si sta lavorando in una precedente edizione di VisualAge per Java (che utilizza EMSRV 6.x/7.0), è possibile collegarsi dalla versione precedente ad un magazzino condiviso in esecuzione su EMSRV 7.1. 

C.4.0 Preparazione per lo sviluppo team  

A questo punto, i programmi del server di magazzino e un magazzino di codifica di origine condiviso sono già installati. Per completare l'impostazione dell'ambiente di sviluppo team, è necessario avviare il server, collegarsi ad esso da un client VisualAge per Java e aggiungere utenti all'elenco utenti del magazzino.

Se il client VisualAge per Java è già installato su una stazione di lavoro, fare riferimento all'aiuto in linea per ottenere ulteriori informazioni sull'impostazione dell'ambiente di sviluppo team. Altrimenti, fare riferimento al team.pdf nella directory pdf. La directory pdf si trova sul CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

Nelle seguenti istruzioni, si suppone che il magazzino condiviso installato sul server sia denominato ivj.dat. Quando viene avviato il programma del server del magazzino, il responsabile deve fornire il percorso del file ivj.dat e la directory di lavoro EMSRV.

C.4.1 Preparazione del server team

Prima che gli sviluppatori del team possano lavorare con il magazzino condiviso, il responsabile deve impostare il server VisualAge per Java ed avviare il programma del server del magazzino EMSRV. Se alcuni sviluppatori desiderano cominciare ad utilizzare VisualAge per Java, Versione 4.0 prima che il server sia pronto, possono prima installare la modalità per utenti autonomi e quindi collegarsi al magazzino condiviso.

C.4.2 Verifica di un collegamento client

Per confermare che il server è stato avviato correttamente, il responsabile deve collegarsi al magazzino condiviso da un client VisualAge per Java, Edizione Enterprise, Versione 4.0. Questa operazione confermerà che il collegamento TCP/IP del server funziona correttamente, che EMSRV è stato avviato con i parametri corretti e che il responsabile sa quali informazioni del server devono essere fornite durante l'installazione del client.

Per informazioni sul collegamento ad un magazzino condiviso, fare riferimento a "Collegamento ad un magazzino condiviso" nell'aiuto in linea di VisualAge per Java oppure nel file team.pdf. Il file team.pdf si trova nella directory pdf. La directory pdf si trova sul CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

C.4.3 Aggiunta di utenti all'elenco utenti del magazzino

Quando un client si collega prima al magazzino condiviso, all'utente viene richiesto di fornire un nome proprietario dello spazio di lavoro. L'utente non può avviare l'IDE senza prima selezionare un nome proprietario dello spazio di lavoro valido dall'elenco di utenti del magazzino.

Per default, VisualAge per Java, Versione 4.0 dispone di un utente chiamato Administrator nell'elenco utenti del magazzino. Ogni utente può scegliere inizialmente Administrator come nome di proprietario dello spazio di lavoro; tuttavia, si consiglia ad ogni utente di fornire al più presto un nome univoco per il collegamento al server. Nell'ambiente di sviluppo dl gruppo di lavoro VisualAge per Java, il controllo delle modifiche è basato sulle regole dell'utente definite, il che significa che ogni sviluppatore deve essere identificato unicamente. Per raggiungere questo obiettivo, il responsabile deve aggiungere tutti all'elenco degli utenti del magazzino. (L'unico utente VisualAge per Java che è in grado di aggiungere altri nomi all'elenco utenti del magazzino è Administrator.)Il nome univoco appartenente a ciascun utente deve corrispondere ad un nome utente del sistema se si utilizza la verifica della parola d'ordine nativa.

Per informazioni sull'aggiunta di utenti all'elenco magazzini, fare riferimento all'aiuto in linea per team di VisualAge per Java oppure al file team.pdf contenuto nella directory pdf. La directory pdf si trova sul CD Funzioni aggiuntive di VisualAge per Java, Edizione Enterprise. Se si dispone di una versione elettronica di VisualAge per Java, fare riferimento alla directory temporanea (in cui sono state estratte le parti). Se non sono state scaricate le parti contenenti i PDF, non si disporrà di tale directory.

Ora che il server è impostato e pronto, gli utenti possono installare i propri client VisualAge per Java. Informazioni sull'installazione dei client team di VisualAge per Java sono reperibili nella Parte B della presente guida.

C.5.0 Limitazioni e problemi noti (EMSRV) 

C.5.1 Prestazioni su connessioni di rete ad alta latenza e banda corta

Il protocollo utilizzato tra client EMSRV e EMSRV normalmente genera la trasmissione di alte velocità di pacchetti al server. Ciò è dovuto al fatto che la maggior parte dell'elaborazione viene effettuata sul client. La maggioranza delle richieste elaborate da EMSRV sono richieste I/O (ad esempio, richieste di scrittura e lettura, blocco di record).

Come risultato di questa architettura, le prestazioni riscontrabili sul client sono fortemente sensibili alla latenza della rete. Una latenza (misurata attraverso round-trip o 'ping') inferiore a 5 ms è in grado di produrre prestazioni accettabili. La latenza LAN è generalmente inferiore a 1 ms, ma una connessione WAN o modem a composizione su una linea telefonica potrebbe avere una latenza fino a 500 ms. Anche disponendo di connessioni DSL ad alta velocità, via cavo, frame relay o ISDN, la latenza è in funzione della distanza tra due punti finali.

In generale, una connessione modem attraverso una linea telefonica non garantisce prestazioni accettabili, poichè connessioni di questo tipo hanno di solito una latenza di 200 ms o più. Anche le connessioni ad alta velocità non garantiscono prestazioni accettabili, a meno che la distanza tra il client e il server sia inferiore a poche centinaia di chilometri.

Il protocollo EMSRV non utilizza particolarmente l'ampiezza di banda, ma tale utilizzo è in funzione del numero di client che utilizzano simultaneamente una connessione.

C.5.2 Limitazioni di collegamento TCP/IP

Il limite di default per i collegamenti client a EMSRV è 512. Questo limite può essere cambiato utilizzando l'opzione di riga comandi -M quando si avvia EMSRV.

Il numero è collegato principalmente alla memoria, ma alcuni accodamenti TCP/IP eseguono al di fuori dei socket di flusso prima che venga raggiunto il limite di memoria. Generalmente, questo numero è superiore a cento ma varia in base a ciascun accodamento (stack).

C.5.3 Rilevamento di collegamenti rilasciati in modo imprevisto

EMSRV utilizza il timer TCP/IP KEEPALIVE per rilevare i collegamenti che sono stati interrotti inaspettatamente quando un client si blocca o viene riavviato. Alcuni accodamenti TCP/IP consentono di modificare il timeout KEEPALIVE. Generalmente, l'impostazione di default è 120 minuti.

EMADMIN può essere utilizzato per elencare i collegamenti e identificare un collegamento che non ha interagito con il server per un lungo periodo di tempo dall'ultima richiesta. Come un collegamento, può essere chiuso utilizzando il comando EMADMIN STOP e l'opzione -k .

C.5.4 Interscambio di differenti versioni di EMSRV e di programmi di utilità EMSRV

VisualAge per Java, Versione 4.0, include i programmi di utilità versione 7.1 di EMSRV e versione 7.0 di EMADMIN.

E' necessario utilizzare EMADMIN 7.0 con EMSRV 7.1. EMADMIN 7.0 non funzionerà correttamente con rilasci di EMSRV precedenti al 7.0.

C.5.5 Limitazioni PAM

Su piattaforme Linux e Solaris, l'autenticazione viene implementata mediante PAM (Password Authentication Modules). Sebbene sia teoricamente consentito utilizzare qualsiasi PAM (modulo) con EMSRV modificando il file di configurazione PAM relativo, in pratica ciò non è possibile.

EMSRV non conversa con i client in un modo interamente compatibile con l'architettura PAM. Ne risulta che l'autenticazione EMSRV funzionerà solo quando il modulo richiede inizialmente una parola d'ordine di testo (fornita dal client).

C.5.6 Parole d'ordine con caratteri non-ASCII non utilizzabili per l'autenticazione con EMSRV 

A causa di un errore nelle librerie runtime C Microsoft, le parole d'ordine contenenti caratteri non-ASCII immesse in risposta alla richiesta:

'Immettere la parola d'ordine dell'utente che ha avviato EMSRV'

non verranno interpretate in modo corretto. La soluzione consiste nel fornire la parola d'ordine con l'opzione -p quando si esegue EMADMIN.

C.5.7 Menu e finestre con caratteri corrotti su NetWare in lingua giapponese

NLM EMSRV per NetWare utilizza NLM User Interface Developer Components (NWSNUT) di Novell. Durante l'esecuzione su NetWare in lingua giapponese, i caratteri grafici utilizzati nei menu e nelle finestre NWSNUT non sono disponibili e verranno visualizzati come caratteri corrotti. Questo non è un errore di NLM EMSRV né di NetWare, ma rappresenta una limitazione della codepage Shift-JIS.

C.5.8 EMADMIN non copia la directory di risorse memorizzate  

Quando EMADMIN 7.0 viene utilizzato per copiare un magazzino VisualAge per Java 4.0, non copia la corrispondente directory di risorse di progetto memorizzate. E' necessario copiare manualmente tale directory.

Parte D. Informazioni sulla migrazione di componenti specifici

Fare riferimento alla sezione 18.0 per importanti informazioni sulla migrazione di classi Swing.

D.1.0 CICS Transaction Server (CICS TS)

Questa versione di VisualAge per Java non supporta CICS(R) Transaction Server. Le classi necessarie per supportare CICS TS 1.3 e versioni precedenti non sono incluse in questa versione. Qualsiasi applicazione CICS TS che si prova a migrare da precedenti versioni di VisualAge per Java non funzionerà nella Versione 4.0 e deve essere cancellata dal magazzino e dallo spazio di lavoro della Versione 4.0.

Se si desidera lavorare con CICS TS 1.3 o versioni precedenti, è necessario continuare ad utilizzare una versione di VisualAge per Java precedente (3.02 o inferiore). Per lo stesso motivo, sarà anche necessario utilizzare una precedente versione di VisualAge per Java (3.02 o inferiore) se si desidera utilizzare l'interfaccia JCICS o il supporto CICS per IIOP. Il supporto del server CICS Transactions non viene fornito perché si basa su JDK 1.1.x.

D.2.0 Bean Data Access

D.2.1. Migrazione dalla Versione 2.0 o 3.0x di VisualAge per Java

I bean Data Access utilizzano interfacce e componenti Swing. Qualsiasi applicazione sviluppata che utilizza i bean deve essere migrata dai vecchi pacchetti Swing JDK 1.1.x ai nuovi pacchetti Swing J2SDK v.1.2.2. Per fare ciò, selezionare le classi e i pacchetti interessati dopo aver installato VisualAge per Java, Versione 4.0, aprire la SmartGuide Correzione/Migrazione e selezionare la casella di spunta Includi pacchetti JDK1.2 ridenominati. In questo modo verranno aggiunte le voci Da/A per Swing e l'utente sarà abilitato a migrare automaticamente i riferimenti Swing a Java 2 SDK. Qualsiasi errore che si verifica durante la migrazione verrà registrato nella finestra Registrazione.

Per ulteriori informazioni sulla corretta migrazione delle proprie applicazioni, fare riferimento al file dell'aiuto in linea dell'Editor di composizione visiva "Direttive di base di correzione/migrazione relative a riferimenti di classi o pacchetti" e al file di attività correlato "Riparazione riferimenti di classi o pacchetti".

D.2.2. Migrazione dalla Versione 3.5 di VisualAge per Java

Non è necessario effettuare alcun passo extra per trasferire i propri bean Data Access se si è passati a VisualAge per Java, Versione 3.5, poichè i bean Data Access nella Versione 3.5 utilizzavano i pacchetti Swing J2SDK v.1.2.2.

D.3.0 Data Access Builder

Il Data Access Builder non è più incluso in VisualAge per Java. Se si desidera utilizzare ancora Data Access Builder, si dovrà continuare a lavorare in una precedente versione di VisualAge per Java.

Non esiste alcuna nuova funzione in VisualAge per Java, Versione 4.0 che sostituisce direttamente la funzionalità fornita precedentemente da Data Access Builder, ma esistono tre componenti in VisualAge per Java che forniscono una funzionalità simile: Bean Data Access, Persistence Builder e l'Ambiente di sviluppo JavaBean Enterprise. Ciascuna funzione offre un diverso approccio per la creazione di classi di accesso ai dati. 

Non è possibile migrare la propria codifica su VisualAge per Java, Versione 4.0 e riutilizzarla con questi strumenti. Sarà necessario creare nuovamente le proprie applicazioni se si desidera utilizzarle nella Versione 4.0. Utilizzare la funzione che meglio si adatta alle proprie esigenze.

Un confronto tra Data Access Builder, Bean Data Access e Persistence Builder viene fornito come appendice di questa guida. 

D.4.0 Ambiente di sviluppo EJB(TM)

D.4.1 Migrazione di bean enterprise da VisualAge per Java, Versione 2.0, Aggiornamento Enterprise

Se sono stati creati bean enterprise in VisualAge per Java, Versione 2.0, aggiornamento Enterprise, e si desidera utilizzarli in VisualAge per Java, Versione 4.0, è necessario completare le seguenti attività nella propria versione corrente di VisualAge per Java, Versione 2.0, aggiornamento Enterprise:

  1. Nel Browser di schema, salvare tutti gli schemi non salvati.
  2. Nel Browser di mappe, salvare tutte le mappe non salvate.
  3. Se sono state apportate modifiche recenti alle mappe o agli schemi dall'ultima creazione di codifica configurata, cancellare la codifica configurata, rigenerarla e verificarla.
  4. Eseguire la versione dei pacchetti (inclusi i pacchetti di schemi e mappe) e dei progetti, quindi, esportare il progetto in formato .dat.

Per completare la migrazione della codifica di bean enterprise in VisualAge per Java, Versione 4.0, seguire i passi riportati nello Scenario 1 o nello Scenario 2 riportati di seguito, a secondo se l'importazione avviene da un magazzino (scelta consigliata) o da un file JAR.

Scenario uno - Importazione da un magazzino
Se si stanno importando i propri bean da un magazzino, seguire questi passi:

  1. Aggiungere allo spazio di lavoro i progetti contenenti i bean enterprise, gli schemi e le associazioni del magazzino. Icone di errore verranno visualizzate accanto ad alcune delle classi caricate.
  2. Creare una edizione aperta per ciascun progetto. Creare anche una edizione aperta di ogni pacchetto contenente vecchie classi generate.
  3. Utilizzare il browser di schemi e mappe per caricare nello spazio di lavoro tutti gli schemi e le associazioni disponibili e, quindi, rigenerare le classi configurate.
  4. Se non è stato creato né uno schema né un'associazione, crearne uno di default e rigenerare la codifica configurata.
  5. Se si decide di lavorare esclusivamente nella Versione 4.0, cancellare qualsiasi classe client test EJB esistente nella pagina Progetti creata precedentemente mediante l'ambiente di sviluppo EJB della Versione 2.0, aggiornamento Enterprise. Tali classi conterranno errori e non funzioneranno nella Versione 4.0 poiché il client test EJB non utilizza più le classi generate. Ricordare che le classi client test non verranno visualizzate nel pannello Tipi EJB della pagina EJB prima della cancellazione, quindi sarà necessario controllare la pagina Progetti per determinare la presenza di classi da cancellare.

Ulteriori informazioni su come eseguire questi passi sono reperibili nell'aiuto in linea VisualAge per Java relativo all'Ambiente di sviluppo EJB.

Scenario due - Importazione da un file JAR
Se i propri bean enterprise sono stati esportati in un file JAR, seguire questi passi:

  1. Sulla pagina EJB, selezionare EJB > Importa bean enterprise per importare il file JAR nello spazio di lavoro di VisualAge per Java, Versione 4.0.
  2. Icone di errore verranno visualizzate accanto a molte delle classi importate, poiché il file JAR non conterrà le associazioni richieste.
  3. Rigenerare schemi, associazioni, classi configurate e verificare qualsiasi client di prova di cui si dispone.
  4. Se si decide di lavorare esclusivamente nella Versione 4.0, cancellare qualsiasi classe client test EJB esistente nella pagina Progetti creata precedentemente mediante l'ambiente di sviluppo EJB della Versione 2.0, aggiornamento Enterprise. Tali classi conterranno errori e non funzioneranno nella Versione 4.0 poiché il client test EJB non utilizza più le classi generate. Ricordare che le classi client test non verranno visualizzate nel pannello Tipi EJB della pagina EJB prima della cancellazione, quindi sarà necessario controllare la pagina Progetti per determinare la presenza di classi da cancellare.

Ulteriori informazioni su come eseguire questi passi sono reperibili nell'aiuto in linea VisualAge per Java relativo all'Ambiente di sviluppo EJB.

D.4.2 Migrazione di bean enterprise da VisualAge per Java, Versione 3.0 o 3.02

Se si dispone di un bean enterprise esistente con una codifica configurata che è stata generata utilizzando VisualAge per Java, Versione 3.0 o 3.02 e si gestirli utilizzando VisualAge per Java, Versione 4.0, è necessario migrare il bean enterprise nella Versione 4.0 e, quindi, cancellare esplicitamente e rigenerare la codifica configurata.

Tuttavia, prima di migrare la propria codifica di bean enterprise nella Versione 4.0, è necessario completare le seguenti attività nella propria versione corrente di VisualAge per Java (Versione 3.0 o Versione 3.02):

  1. Nel Browser di schema, salvare tutti gli schemi non salvati.
  2. Nel Browser di mappe, salvare tutte le mappe non salvate.
  3. Se sono state apportate modifiche recenti alle mappe o agli schemi dall'ultima creazione di codifica configurata, cancellare la codifica configurata, rigenerarla e verificarla.
  4. Eseguire la versione dei pacchetti (inclusi i pacchetti di schemi e mappe) e dei progetti, quindi, esportare il progetto in formato .dat.

Per migrare la codifica bean enterprise e rigenerare la codifica configurata, completare i seguenti passi in VisualAge per Java, Versione 4.0, nell'ordine esatto in cui sono elencati:

  1. Importare il file di magazzino del progetto nello spazio di lavoro.
  2. Creare un'edizione aperta del progetto. Creare anche un'edizione aperta di ogni pacchetto contenente codifica configurata che si desidera cancellare.
  3. Nel Workbench, fare clic sul separatore EJB.
  4. Nel pannello Bean Enterprise, selezionare il bean o il gruppo di bean enterprise per i quali si desidera cancellare la codifica configurata.
  5. Selezionare EJB > Cancella.
  6. Fare clic su Codifica configurata per cancellare la codifica configurata.
  7. Migrare le associazioni (se presenti) seguendo le istruzioni riportate nella sezione D.4.3 (se si sta migrando dalla Versione 3.0) o nella sezione D.4.4 (se si sta migrando dalla Versione 3.02).
  8. Verificare che nessuna classe bean e nessun elemento principale delle classi bean contenga errori.
  9. Rigenerare i propri bean access EJB (se presenti) completando i seguenti passi:
    1. Nella pagina EJB del Workbench, selezionare il bean enterprise associato al bean access che si desidera migrare.
    2. Dal menu EJB, selezionare Aggiungi > Bean Access per aprire la SmartGuide Crea bean Access, quindi fare clic sul pulsante Fine. Tutte le modifiche necessarie relative alla migrazione del bean access vengono apportate automaticamente.
  10. Creare nuovamente la codifica configurata.
  11. Se si decide di lavorare esclusivamente nella Versione 4.0, cancellare qualsiasi classe client test EJB esistente nella pagina Progetti creata precedentemente mediante l'ambiente di sviluppo EJB della Versione 3.0 o 3.02. Tali classi conterranno errori e non funzioneranno nella Versione 4.0 poiché il client test EJB non utilizza più le classi generate. Ricordare che le classi client test non verranno visualizzate nel pannello Tipi EJB della pagina EJB prima della cancellazione, quindi sarà necessario controllare la pagina Progetti per determinare la presenza di classi da cancellare.
  12. Se sono stati creati precedentemente file JAR client in VisualAge per Java, Versione 3.0, 3.02 o 3.5, è necessario ricreare i propri file JAR client in VisualAge per Java, Versione 4.0.

D.4.3 Migrazione di associazioni EJB da VisualAge per Java, Versione 3.0

Quando si aggiunge, edita e cancella un'associazione in un gruppo EJB creato nella Versione 3.0, VisualAge per Java converte automaticamente tutte le associazioni presenti nel gruppo EJB nel formato delle nuove associazioni. Per completare il processo di migrazione, apportare manualmente le seguenti modifiche:

Questi metodi non sono stati convertiti automaticamente a causa dell'alta probabilità che tali metodi vengano modificati manualmente. VisualAge per Java aggiungerà automaticamente i richiami quando vengono creati nuovi bean nella Versione 4.0.

Se viene importato un bean entità CMP della versione 3.0 o precedente in un gruppo EJB, le cui associazioni sono state migrate, e viene aggiunto un bean nuovo che ha eredità dal bean entità CMP importato, la classe di bean del nuovo bean visualizza X rosse in più metodi. Ciò avviene perché la classe di bean del bean importato non avrà i metodi the _initLinks, _getLinks e _removeLinks. E' necessario aggiungere manualmente tali metodi alla classe bean del bean importato.   

Quando si è pronti per configurare la codifica del bean enterprise in un server di applicazioni di produzione, assicurarsi di configurare anche il file JAR runtime contenente la codifica runtime richiesta dai bean di accesso e dalle associazioni. Questo file JAR deve essere configurato sul proprio server di applicazione e incluso nel classpath dello stesso server. Ulteriori informazioni sul file JAR sono reperibili nella guida in linea di Ambiente di sviluppo EJB.

D.4.4 Migrazione di associazioni EJB da VisualAge per Java, Versione 3.02

Quando si apre per la prima volta un gruppo EJB con associazioni create nella Versione 3.02 di VisualAge per Java, il gruppo conterrà icone di errori accanto alle classi link generate. Quando si aggiunge, edita o cancella un'associazione in un gruppo EJB di questo tipo, VisualAge per Java ripara automaticamente le classi link per tutte le associazioni presenti nel gruppo EJB. Se si decide di non apportare modifiche all'associazione sarà comunque necessario selezionarla nel pannello Proprietà della pagina EJB e selezionare Edita dal menu concatenato per aprire l'editor di associazioni. Quindi, fare clic su OK per completare il processo di migrazione.

VisualAge per Java eliminerà automaticamente alcuni metodi correlati ad associazioni generati in VisualAge per Java 3.02. I metodi rimossi sono metodi che, date le caratteristiche dell'associazione, non funzionano correttamente nella Versione 4.0. Ad esempio, se un ruolo fa parte della chiave primaria, il metodo set oer tale ruolo non è valido. Il metodo dovrebbe essere stato generato automaticamente nella Versione 3.02 e non può essere generato nella Versione 4.0.

D.5.0 Enterprise Access Builder(EAB) e e-connector  

D.5.1 Enterprise Access Builder

D.5.1.1 Nuovo supporto per connector
Enterprise Access Builder supporta ora i connector Common Connector Framework (CCF) e Java 2, Enterprise Edition (J2EE) Connector Architecture. Enterprise Access Builder dispone di nuovi strumenti per la migrazione di bean EAB Record, Command, Navigator e di sessione da un formato CCF a un formato J2EE Connector Architecture. Inoltre, le seguenti SmartGuide e i seguenti editor sono stati aggiornati per il nuovo supporto di J2EE Connector Architecture:

Per ulteriori informazioni sul nuovo supporto per IBM Connector e Tool per J2EE(TM) - Beta e sui nuovi Migrator EAB, fare riferimento all'aiuto in linea di Enterprise Access Builder.

D.5.1.2 Rigenerazione e editazione di record e Command
Se si effettua la migrazione di applicazioni EAB da una precedente versione di VisualAge per Java alla Versione 4.0, si potrebbe voler rigenerare i record e i Command. Se rigenerati, funzioneranno meglio nella Versione 4.0. 

Precedentemente, se è stato selezionato "Diretto" e "Nomi abbreviati" senza selezionare "Classi interne", i nomi dei record generati
risultavano essere spesso più grandi di quanto necessario. Ciò provocava a volte che i nomi generati eccedevano il limite di 255 impostato per il nome file Windows. La SmartGuide Crea record da tipo di record è stata ottimizzata per la creazione di nomi ridotti al massimo quando vengono selezionate le opzioni precedenti. Tuttavia, se si procede con la rigenerazione con tali opzioni, poiché i nomi di record potrebbero cambiare, le applicazioni potrebbero esserne influenzate.

Se il Command EAB è stato creato nella Versione 2.0x, non è possibile editarlo nell'Editor di comandi. Tuttavia, è possibile editarlo nell'Editor di composizione visiva. La versione corrente dell'ambiente run-time permette l'esecuzione di Command della Versione 2.0x.

D.5.1.3 Configurazione delle proprie applicazioni
La Versione 4.0 rappresenta un rilascio di transizione per Enterprise Access Builder (EAB). La vecchia architettura CCF (Common Connector Framework), che era basata su EAB, sta per essere trasferita alla nuova architettura J2EE Connector. La documentazione EAB tratta tale transizione e le differenze tra le architetture. Per questo rilascio sono supportate entrambe le architetture. Sotto l'aspetto della configurazione, ciò implica la presenza di alcune differenze. Per i dettagli, consultare la sezione sulla configurazione presente nella documentazione EAB. Il seguente paragrafo costituisce una semplice panoramica di configurazione.

Per applicazioni esistenti, è possibile continuare come in passato. Configurare le proprie applicazioni con i file eab\runtime30\eablib.jar, ccf.jar, recjava.jar e i file JAR che il connector richiede al runtime. Per le nuove applicazioni a cui sono stati aggiunti alcuni componenti collegati all'architettura J2EE, come record e Command, configurare con eab\runtime35\eablib.jar. Tale file è bimodale, cioé supporta entrambe le architetture. Inoltre saranno necessari altri file JAR relativi solo a J2EE, specificati nella sezione sulla configurazione presente nella documentazione EAB.

D.5.2 E-connector

La seguente sezione contiene informazioni su IMS connect, CICS connector e sulla migrazione di e-connector.

Important : A causa di una limitazione nel supporto del CDFS (CD-ROM file system) su Windows 98, l'installazione di alcuni file di connector e-business dal CD-ROM potrebbe non riuscire e determinare la visualizzazione di una o più finestre di dialogo di errore, riportate di seguito, in base ai connector selezionati:

Tutti i file non installati sono memorizzati in un file zip (econnfix.zip) ubicato nella root del CD del prodotto. Se si sta provando ad installare VisualAge per Java su Windows 98 e si riceve uno dei messaggi descritti in precedenza, decomprimere econnfix.zip nella directory in cui è stato installato il prodotto (ad esempio, eseguendo il comando unzip econnfix.zip -d c:\Program Files\IBM\VisualAge per Java\ dove c:\Program Files\IBM\VisualAge per Java\ rappresenta la directory di installazione del prodotto). Una volta che tali file sono posizionati, i connector funzioneranno correttamente.

D.5.2.1 IMS Connect
Il supporto per IMS TCP/IP OTMA Connection (IMS TOC) verrà sospeso nel marzo 2001. Si raccomanda agli utenti di passare da IMS TOC a IMS Connect ed utilizzare quest'ultimo.

IMS Connect è un prodotto IBM, SMP-installabile, disponibile separatamente (non è incluso in VisualAge per Java) che può essere utilizzato insieme a VisualAge per Java IMS Connector per accedere a IMS. Dopo la migrazione da IMS TOC a IMS Connect, è possibile continuare ad utilizzare tutti i programmi IMS Connector per Java, senza doverli modificare o aggiornare.

D.5.2.2 CICS Connector
Il comportamento dell'indicatore CICSELUW in ECIInteractionSpec è stato modificato per la corretta conformità all'architettura CCF Connector. Nei precedenti rilasci, questo indicatore presentava per default FALSE nel constructor e, a prescindere dalla presenza di un effettivo Coordinator, determinava sempre l'estensione della LUW.

In questo rilascio, l'indicatore CICSELUW ha per default TRUE nel constructor ECIInteractionSpec se un effettivo Coordinator CCF (ad esempio, JavaCoordinator) è presente. A meno che non sia stata esplicitamente impostata nella vecchia codifica VisualAge per Java, la proprietà CICSELUW nella vecchia codifica avrà per default TRUE una volta migrata in VisualAge per Java, Versione 4.0.

Quando non è presente alcun Coordinator effettivo, questo indicatore viene ignorato e tutte le applicazioni (quelle vecchie e quelle nuove create in VisualAge per Java, Versione 4.0) si comporteranno come se l'indicatore CICSELUW rispondesse a FALSE. Quindi, l'impostazione esplicita di tale indicatore non avrà alcun effetto a meno che non venga impiegato un effettivo coordinator nel proprio ambiente.

D.5.2.3 Migrazione di e-connector
Mentre la maggior parte delle versioni precedenti di VisualAge per Java possono coesistere con la Versione 4.0, la coesistenza di diversi livelli di e-connector non è supportata.

Migrazione da VisualAge per Java, Versione 3.0x o Versione 3.5.x

Se si dispone di e-connector installati, seguire uno dei due seguenti scenari di migrazione per migrare correttamente da una Versione 3.0x o 3.5.x di VisualAge per Java alla Versione 4.0.

La differenza tra i due scenari è rappresentata dalla fase in cui i connector vengono migrati.

Nello Scenario 1 i connector vengono migrati durante il processo di installazione iniziale. Dopo aver completato i passi in questo scenario, si disporrà di VisualAge per Java, Versione 3.0x o 3.5.x senza connector, insieme a VisualAge per Java, Versione 4.0 con connector.

Nello Scenario 2, i connector vengono migrati dopo il processo di migrazione iniziale. Dopo aver completato i passi in questo scenario, si disporrà di VisualAge per Java, Versione 4.0 senza connector, insieme a VisualAge per Java, Versione 3.0x o 3.5.x con connector. Successivamente, è possibile disinstallare i connector della Versione 3.0x o 3.5.x e installare quelli della Versione 4.0.

Scenario di migrazione 1

  1. Eseguire la versione di tutti i progetti di Versione 3.0x o 3.5.x contenenti connector o codifica EAB.
  2. Esportare tali progetti e le relative risorse in una directory al di fuori della struttura di installazione di VisualAge per Java.
  3. Eliminare tutti questi progetti dallo spazio di lavoro 3.0x o 3.5.x.
  4. Eliminare tutte le funzioni CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina(R), IMS(TM) e MQSeries(R) dallo spazio di lavoro
  5. Uscire dall'IDE Versione 3.0x o 3.5.x.
  6. Disinstallare i connector di VisualAge per Java Versione 3.0x o 3.5.x seguendo questi passi:
    1. Dal menu Start di Windows, selezionare Start > Impostazioni > Pannello di Controllo.
    2. Fare doppio clic su Aggiungi/Rimuovi programmi. Selezionare il separatore Installa/Disinstalla.
    3. Selezionare IBM Connector . Fare clic su Aggiungi/Rimuovi.
    4. Confermare la disinstallazione dei connector e dei relativi componenti.
    5. Fare clic su OK nella finestra Rimuovi programmi.

  7. Per evitare conflitti ed errori durante la futura installazione di connector, le variabili di ambiente non devono contenere alcun riferimento ai connector rimossi. Per editare le variabili di ambiente:

    Windows NT e Windows 2000

    1. Dal menu Start, selezionare Impostazioni > Pannello di Controllo.
    2. Fare doppio clic sull'icona Sistema. Selezionare il separatore Ambiente.
    3. In CLASSPATH, PATH e NLS PATH eliminare i riferimenti a IBM Connectors o IBM\Connectors.

    Windows 98

    1. Effettuare il backup del file c:\autoexec.bat
    2. Dal prompt dei comandi, immettere edit c:\ autoexec.bat 
    3. Nelle istruzioni SET CLASSPATH, SET PATH e SET NLS PATH, cancellare ogni riferimento a IBM Connector o IBM\Connector.
  8. Installare VisualAge per Java, Versione 4.0.
  9. Aggiungere le funzioni desiderate CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS e MQSeries allo spazio di lavoro della Versione 4.0.
  10. Importare i propri progetti nello spazio di lavoro Versione 4.0 per completare la migrazione della propria codifica 1.1.x. Se si utilizzano SAP R/3 Access Builder e Connector, fare riferimento alla nota posta alla fine di questi passi. 
  11. E' possibile disinstallare VisualAge per Java, Versione 3.0x o 3.5.x una volta migrata tutta la codifica da conservare in VisualAge per Java 4.0. 
Se si utilizzano connector SAP, è necessario rigenerare le classi che erano state generate con VisualAge per Java, Versione 3.0x o 3.5.x.

Access Builder e Connector per SAP R/3 forniscono anche alcune classi di utilità (ad esempio, LogonBean) basate su Swing 1.0.3. Queste classi vengono sostituite da classi basate su Swing 1.1. Quando si passa dalla Versione 3.0x o 3.5.x alla Versione 4.0, migrare le classi basate su Swing 1.0.3 al livello 1.1 per continuare ad utilizzare le classi di utilità fornite da Access Builder e Connector per SAP R/3. Per questa operazione è possibile utilizzare lo strumento Correzione/Migrazione IDE.

Scenario di migrazione 2

  1. Installare VisualAge per Java Versione 4.0, senza installare Enterprise Access Builder for Transactions:
    1. Installare VisualAge per Java, Versione 4.0. Seguire le istruzioni visualizzate sullo schermo.
    2. Nella pagina del tipo di impostazione, selezionare Personalizzata. Fare clic su Avanti.
    3. Selezionare tutti i componenti da installare ma non selezionare Transactions Access Builder. Fare clic su Avanti una volta completata la selezione dei componenti da installare. Se si è ritornati al pannello di installazione dopo aver provato ad installare Transactions Access Builder e non si desidera installare i connector, deselezionare la casella Transactions Access Builder e fare clic su Avanti.
    4. Continuare a seguire le istruzioni su schermo per completare l'installazione.
      E' possibile continuare a lavorare con i connector di VisualAge per Java, Versione 3.0x o Versione 3.5.x.

Quando si desidera installare i connector VisualAge per Java, Versione 4.0, è necessario disinstallare la Versione 3.0x/3.5.x oppure  disinstallare i connector 3.0x/3.5.x seguendo i passi descritti nello scenario di migrazione 1. Una volta disinstallati i connector Versione 3.0x/3.5.x oppure VisualAge per Java Versione 3.0x/3.5.x, è possibile installare i connector per la Versione 4.0 seguendo questi passi:

  1. Installare VisualAge per Java, Versione 4.0. Seguire le istruzioni visualizzate sullo schermo.
  2. Nella pagina Manutenzione programma, selezionare Modifica. Fare clic su Avanti.
  3. Selezionare Transaction Access Builder. Fare clic su Avanti e seguire le istruzioni sullo schermo per continuare l'installazione del componente.
  4. Aggiungere i connector all'IDE di VisualAge per Java. Per eseguire questa operazione, fare riferimento all'aiuto in linea.

Migrazione da VisualAge per Java, Versione 3.5 o Versione 3.5.3

Durante la migrazione da VisualAge per Java, Versione 3.5 o 3.5.3 a VisualAge per Java, Versione 4.0, i connector IBM installati con VisualAge per Java 3.5 o 3.5.3 devono prima essere disinstallati per assicurare che venga installata la corretta versione di connector IBM con VisualAge per Java 4.0.

Se si prova ad installare VisualAge per Java, Versione 4.0 prima di rimuovere i connector IBM Versione 3.5 o 3.5.3, verrà visualizzata una finestra di dialogo che informa di migrare tutte le applicazioni che utilizzano connector IBM prima di procedere con l'installazione della Versione 4.0.

Per migrare le applicazioni e disinstallare i connector IBM Versione 3.5 o 3.5.3, seguire i passi riportati di seguito.

  1. Eseguire la versione di tutti i progetti di Versione 3.5 o 3.5.3 contenenti connector o codifica EAB.
  2. Esportare tali progetti e le relative risorse in una directory al di fuori della struttura di installazione di VisualAge per Java.
  3. Eliminare tutti questi progetti dallo spazio di lavoro 3.5 o 3.5.3.
  4. Eliminare tutte le funzioni CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS e MQSeries dallo spazio di lavoro.
  5. Uscire dall'IDE Versione 3.5 o 3.5.3.
  6. Disinstallare i connector di VisualAge per Java Versione 3.5 o 3.5.3 seguendo questi passi:
    1. Dal menu Start di Windows, selezionare Start > Impostazioni > Pannello di Controllo.
    2. Fare doppio clic su Aggiungi/Rimuovi programmi. Selezionare il separatore Installa/Disinstalla.
    3. Selezionare IBM Connector. Fare clic su Aggiungi/Rimuovi.
    4. Confermare la disinstallazione dei connector e dei relativi componenti.
    5. Fare clic su OK nella finestra Rimuovi programmi.

  7. Per evitare conflitti ed errori durante la futura installazione di connector, le variabili di ambiente non devono contenere alcun riferimento ai connector rimossi. Per editare le variabili di ambiente:

    Windows NT e Windows 2000

    1. Dal menu Start, selezionare Impostazioni > Pannello di Controllo.
    2. Fare doppio clic sull'icona Sistema. Selezionare il separatore Ambiente.
    3. In CLASSPATH, PATH e NLS PATH eliminare i riferimenti a IBM Connectors o IBM\Connectors.

    Windows 98

    1. Effettuare il backup del file c:\autoexec.bat
    2. Dal prompt dei comandi, immettere edit c:\ autoexec.bat 
    3. Nelle istruzioni SET CLASSPATH, SET PATH e SET NLS PATH, cancellare ogni riferimento a IBM Connector o IBM\Connector.
  8. Installare VisualAge per Java, Versione 4.0.
  9. Aggiungere le funzioni desiderate CICS, Host-On-Demand, IBM Enterprise Access Builder, Encina, IMS e MQSeries allo spazio di lavoro della Versione 4.0.

Disinstallazione connector

Se si disinstalla VisualAge per Java, Versione 4.0, i connector verranno automaticamente disinstallati. Per evitare conflitti ed errori durante la futura installazione di connector, le variabili di ambiente non devono contenere alcun riferimento ai connector rimossi. Per modificare le variabili di ambiente, seguire i passi appropriati illustrati di seguito:

Windows NT e Windows 2000

  1. Dal menu Start, selezionare Impostazioni > Pannello di Controllo.
  2. Fare doppio clic sull'icona Sistema. Selezionare il separatore Ambiente.
  3. In CLASSPATH, PATH e NLS PATH eliminare i riferimenti a IBM Connectors o IBM\Connectors.

Windows 98

  1. Effettuare il backup del file c:\autoexec.bat
  2. Al prompt di comandi, immettere edit c:\ autoexec.bat 
  3. Nelle istruzioni SET CLASSPATH, SET PATH e SET NLS PATH, cancellare ogni riferimento a IBM Connector o IBM\Connector.

Solo Windows 98: Potrebbe essere necessario cancellare manualmente la directory di e-connector (che, per default, è C:\IBM Connectors) dopo aver disinstallato VisualAge per Java. 

D.6.0 Enterprise Toolkit per AS/400 (ET/400)

D.6.1 Migrazione dalla Versione 2.0 di VisualAge per Java

Le classi generate utilizzando Enterprise Toolkit per AS/400 con VisualAge per Java, Versione 2.0 non sono compatibili con le classi Java generate utilizzando Enterprise Toolkit per AS/400 con VisualAge per Java, Versione 4.0. Il motivo di tale incompatibilità consiste nel fatto che le classi ET/400 Java della Versione 2.0 utilizzavano AWT (Abstract Windowing Toolkit) mentre le classi ET/400 Java della Versione 4.0 utilizzano Java 2 SDK Swing.

Tuttavia, le classi fornite nella Versione 2.0 possono ancora essere reperite nel pacchetto com.ibm.ivj.et400.util.awt,, fornito con VisualAge per Java, Versione 4.0. Se si desidera utilizzare classi generate nella Versione 2.0 in VisualAge per Java, Versione 4.0, sarà necessario modificare qualsiasi riferimento nelle classi Versione 2.0 dal pacchetto com.ibm.ivj.et400.util al pacchetto com.ibm.ivj.et400.util.awt. Ciò può essere fatto utilizzando la SmartGuide Correzione/Migrazione fornita con VisualAge per Java. Qualsiasi errore che si verifica durante la migrazione verrà registrato nella finestra Registrazione. Per informazioni sull'utilizzo di questa SmartGuide, fare riferimento all'aiuto in linea.

D.6.2 Migrazione dalla Versione 3.0 o 3.02 di VisualAge per Java

Se sono state generate classi Java utilizzando la SmartGuide ET/400 Conversione file di visualizzazione con VisualAge per Java, Versione 3.0 o 3.02, tali classi non sono compatibili con quelle generate mediante la stessa SmartGuide della Versione 4.0. 

Tale incompatibilità esiste perché la codifica generata nelle versioni 3.0 e 3.02 utilizza classi non consigliabili quali AS400SVisualTextField e Subfile, mentre la codifica generata nella Versione 4.0 utilizza bean JFormatted. Tutte le classi sconsigliate possono ancora essere reperite nel pacchetto com.ibm.ivj.et400.util, incluso in VisualAge per Java, Versione 4.0. Se si desidera utilizzare le classi generate nella Versione 3.0 o 3.02, è necessario utilizzare lo strumento Correzione/Migrazione per convertire tutte le classi migrate in modo che facciano riferimento ai nuovi nomi di pacchetto Swing Java 2 SDK. Ciò può avvenire selezionando le classi interessate, aprendo lo strumento Correzione/Migrazione e selezionando la casella di spunta Includi pacchetti ridenominati JDK 1.2. In questo modo i riferimenti Swing verranno automaticamente migrati a Java 2 SDK. Per ulteriori informazioni sull'esecuzione di questa attività, fare riferimento all'aiuto in linea. Qualsiasi errore che si verifica durante la migrazione verrà registrato nella finestra Registrazione.

La SmartGuide Crea file secondario non è inclusa in VisualAge per Java, Versione 4.0. E' stata sostituita da bean DFU più potenti e dal bean JFormattedTable. Se si desidera continuare ad utilizzare la SmartGuide Crea file secondario per generare codifica, è necessario continuare a lavorare con una versione precedente (3.02 o inferiore) di VisualAge per Java. Tutta la codifica generata mediante la SmartGuide nella Versione 3.0 o 3.02 può essere migrata alla Versione 4.0 poiché le classi necessarie alla codifica generata sono ancora supportate e sono reperibili nel pacchetto com.ibm.ivj.et400.util. Seguire gli stessi passi riportati nel precedente paragrafo per migrare la propria codifica. 

D.7.0 Enterprise Toolkit per OS/390 (ET/390)

La versione di ET/390 da utilizzare per lo sviluppo di applicazioni OS/390 dipende dal livello SDK disponibile sui sistemi o sulle applicazioni middleware OS/390 e dal livello SDK supportato da VisualAge per Java (comprendente ET/390).

Su sistemi e applicazioni middleware OS/390, sono disponibili due livelli SDK, come illustrato nella seguente tabella:

Sistema o applicazione middleware Livello SDK
OS/390 SDK 1.1.8, 1.3.0
WebSphere Application Server, Versione 3.0 SDK 1.1.8
CICS Transaction Server, Versione 1.3 SDK 1.1.8 per transazioni interpretate e compilate
DB2 Universal Database, Versioni 5 e 6 SDK 1.1.8 solo per procedure memorizzate compilate

In VisualAge per Java, le diverse versioni del prodotto supportano diversi livelli SDK, come illustrato nella seguente tabella:

VisualAge per Java Livello SDK
Versioni 3.5, 3.5.3 e 4.0 SDK 1.2.2
Versione 3.02 SDK 1.1.8

Le seguenti sezioni descrivono i tipi di applicazioni OS/390 che è possibile sviluppare utilizzando le diverse versioni di ET/390.

VisualAge per Java, Versioni 3.5, 3.5.3 e 4.0

ET/390 in VisualAge per Java, Versioni 3.5, 3.5.3 e 4.0, è indirizzato principalmente ai seguenti tipi di applicazioni:

Per applicazioni interpretate in esecuzione su WebSphere Application Server, Versione 3.0, è necessario creare le proprie classi di applicazione in modo che possano lavorare con le API Java sul livello SDK 1.1.8. Una volta create, è possibile esportare le classi in un'unità NFS, rendendole disponibili sul sistema OS/390. Quindi, è possibile eseguire e sottoporre a debug le proprie applicazioni facendo clic sulle voci di menu Esegui main e Debug main dall'IDE di VisualAge per Java.

Per applicazioni interpretate, autonome, in esecuzione sul sistema OS/390, è necessario creare le proprie classi di applicazione in modo che possano lavorare con le API Java sul livello SDK 1.3.0. Una volta create, è possibile esportare le classi in un'unità NFS, rendendole disponibili sul sistema OS/390. Quindi, è possibile eseguire la propria applicazione facendo clic sulla voce di menu Esegui main dall'IDE di VisualAge per Java.

Per dettagli sulla creazione, l'esportazione, l'esecuzione e il debug di applicazioni interpretate, fare riferimento all'aiuto in linea per ET/390.

VisualAge per Java, Versione 3.02

ET/390 in VisualAge per Java, Versioni 3.0.2, è indirizzato principalmente ai seguenti tipi di applicazioni:

D.8.0 Enterprise Toolkit for Workstations (ET/WS)

Enterprise Toolkit for Workstations (ET/WS) e il compilatore ad alte prestazioni (HPJ) non sono inclusi in questo rilascio di VisualAge per Java. Se si desidera utilizzare ancora Enterprise Toolkit for Workstations, si dovrà continuare a lavorare in una precedente versione di VisualAge per Java (3.02 o precedente).

Non esiste alcuna nuova funzione in VisualAge per Java, Versione 4.0 che sostituisce le funzioni precedentemente fornite tramite ET/WS. Una funzionalità simile a quella inclusa in ET/WS può essere reperita nel compilatore "Just-in-time", che è parte della Java virtual machine. La Java virtual machine è inclusa in IBM Developer Kit, Java Technology Edition, v1.2.2, PTF 9.

Il compilatore JIT compila la codifica di byte nella codifica di esecuzione direttae, quindi, esegue i programmi. La codifica di byte viene preservata e resta utilizzabile; tuttavia, la codifica (dopo la compilazione con JIT) viene eseguita più rapidamente. Per ulteriori informazioni visitare il sito web Sun(TM) http://java.sun.com.

D.9.0 Controllo versione esterno 

Quando si passa da VisualAge per Java, Versione 3.5 alla Versione 4.0, è possibile continuare ad utilizzare il Controllo versione esterno su progetti sui quali era stato utilizzato nella versione 3.5. Se l'icona del Controllo versione esterno non appare, selezionare Strumenti > Controllo versione esterno > Aggiorna progetto.

Può essere necessario riavviare l'API Remote Access to Tools dalla finestra di dialogo Opzioni. Selezionare Finestre > Opzioni per aprire la finestra di dialogo Opzioni. Selezionare API Remote Access to Tools e fare clic sul pulsante API Remote Access to Tools per avviarla.

D.10.0 Ambiente di sviluppo IDL

Se è stato utilizzato il compilatore IDL-Java fornito da IBM Component Broker Series o dalla funzione CICS IIOP Server Support, sarà necessario definire manualmente la stringa di richiamo del compilatore IDL-Java nelle seguenti finestre di dialogo:

Pagina Compilatore IDL-Java della finestra di dialogo Opzioni (accessibile dal menu Finestre). Modificare la stringa nel campo Comando.

Finestra di dialogo Modifica opzioni di compilazione IDL-Java. Nella pagina IDL, selezionare IDL > Modifica opzioni di compilazione.  Modificare la stringa nel campo Comando.

Per ulteriori informazioni sulla modifica della stringa e sull'apertura della pagina IDL, fare riferimento alla documentazione in linea relativa all'Ambiente di sviluppo IDL.

Per informazioni sul supporto IIOP CICS, fare riferimento alla sezione 1.0 della Parte D.

D.11.0 IDE (Integrated Development Environment)

Il livello JDK è stato modificato a partire dalla Versione 3.5 (ora è JDK 1.2.2 PTF 9).

Se la libreria di classi java VisualAge per Java, Versione 3.5 è stata modificata sostituendo tutti i pacchetti o le classi contenute oppure aggiungendo pacchetti e classi, tali modifiche non verranno automaticamente riprodotte nella libreria di classi java della Versione 4.0 dopo la migrazione; sarà di nuovo necessario modificare manualmente la libreria. 

La libreria di classi java era interamente per sola lettura in VisualAge per Java precedentemente alla Versione 3.5.

D.12.0 Ambiente di sviluppo JSP/Servlet

Se si sta migrando da una versione precedente di VisualAge per Java a VisualAge per Java, Versione 4.0, i due file seguenti verranno sovrascritti dalle nuove versioni e qualsiasi modifica ad essi apportata verrà persa:

E' possibile effettuare copie di riserva di questi file prima di migrare alla Versione 4.0 e aggiungere le modifiche alle nuove versioni dei file dopo aver completato la migrazione a VisualAge per Java, Versione 4.0. Non è consigliabile copiare semplicemente le vecchie versioni dei file sulle nuove versioni poiché queste ultime contengono  informazioni non presenti nelle vecchie versioni.

D.13.0 Assistente per la migrazione per ActiveX

L'Assistente per la migrazione per ActiveX non è incluso in questo rilascio di VisualAge per Java. E' possibile migrare alla Versione 3.5.3 la codifica creata con l'Assistente per la migrazione in precedenti versioni (3.02 o precedenti) di VisualAge per Java seguendo i passi generali sulla migrazione riportati nella Parte B. Non esiste alcuna funzione in VisualAge per Java, Versione 4.0 che sostituisce la funzionalità precedentemente fornita mediante l'Assistente per la migrazione per ActiveX. 

D.14.0 Persistence Builder  

Nota: Non è necessario applicare Persistence Builder FixPak 3.5.1 o FixPak 3.5.2 (disponibile su VADD) a VisualAge per Java, Versione 4.0. Tali correzioni sono già state incorporate nella codifica della Versione 4.0.

Utilizzare VisualAge per Java per rigenerare codifica da qualsiasi precedente rilascio di Persistence Builder.

D.14.1 Aggiornamento specifico dalla Versione 2.0

Le seguenti istruzioni di migrazione si applicano se si sta effettuando l'aggiornamento da VisualAge per Java, Versione 2.0:

  1. Eseguire la versione di tutti i progetti appartenenti alle proprie applicazioni Persistence Builder.
  2. Dopo aver migrato la codifica in VisualAge per Java, Versione 4.0, aggiungere i progetti allo spazio di lavoro della Versione 4.0. Si riscontreranno problemi con le classi di servizi poiché alcuni converter non sono più inclusi in VisualAge per Java. Per correggere tali problemi, generare le "classi e interfacce di servizio dati" per il modello di oggetto e i problemi verranno risolti dai servizi per la creazione della codifica. 
  3. La superclasse per i converter è stata spostata nel progetto: VisualAge Persistence Common Runtime. E' necessario cambiare la superclasse dei composer in: com.ibm.vap.converters.VapAbstractConverter.
  4. La superclasse composer è stata inoltre spostata in un nuovo progetto. Sarà necessario cambiare la superclasse dei composer in: com.ibm.vap.composers.VapAttributeComposer

Per ulteriori informazioni sull'esecuzione di questi passi, fare riferimento alla documentazione in linea relativa a Persistence Builder.

D.14.2 Aggiornamento da tutte le precedenti versioni (incluso la Versione 2.0) 

Quando si caricano modelli, associazioni o schemi disponibili dai browser di modelli, gli interni dei metadati vengono modificati. Non è possibile quindi caricare in modo sicuro i metadati in uno spazio di lavoro che sia di un rilascio precedente alla Versione 4.0. Il modello, l'associazione o lo schema non apparirà corretto. Salvare il modello, l'associazione o lo schema.

Nota: Le seguenti informazioni si applicano solo se si sta migrando dalla Versione 2.0 o 3.0x di VisualAge per Java. Non si applicano, invece, se si sta migrando dalla Versione 3.5.

Le classi create in precedenti rilasci per interrogazioni personali presenteranno errori. Il framework delle interrogazioni personalizzate attiva un oggetto Throwable per abilitare la funzione di rilevamento delle eccezioni che si verificano quando viene richiamata un'interrogazione personalizzata. Pertanto, le interrogazioni personalizzate esistenti verranno visualizzate nell'IDE come contenenti un errore non risolto (contrassegnate da una X rossa), poiché non stanno gestendo l'eccezione attivata. Per risolvere questa condizione, rilevare o attivare l'eccezione dall'interrogazione personalizzata.

Ulteriori informazioni su questi errori sono reperibili nell'aiuto in linea di VisualAge per Java.

Modifiche al supporto runtime 
Il nome del progetto che contiene i pacchetti dei prerequisiti javax del runtime di Persistence Builder ha modificato i nomi. E' possibile che questo renda necessario nuovamente la determinazione del percorso progetto per gli elementi del programma che utilizzano Persistence Builder, nel modo seguente:

  1. Selezionare la classe.
  2. Dal menu Selezionato o dal menu concatenato della classe, selezionare Esegui > Verifica percorso di classe.
  3. Fare clic sul pulsante Elabora ora accanto alla casella di spunta Percorso progetto.
  4. Per salvare l'impostazione di percorso rielaborata, selezionare la casella di spunta Salva nel magazzino (come default). Se l'impostazione viene salvata, viene creata una nuova edizione della classe.
  5. Selezionare OK.

D.15.0 RMI Access Builder

RMI Access Builder non è incluso in VisualAge per Java, Versione 4.0. E' possibile importare le vecchie classi generate e i vecchi progetti di librerie run-time nello spazio di lavoro della Versione 4.0, ma non sarà possibile eseguire il Remote Object Invocation Manager (ROIM) poiché non è incluso. Si dovrebbe essere a conoscenza del nuovo modello di sicurezza della piattaforma Java 2 e di come le sue limitazioni potrebbero influenzare le applicazioni RMI Access Builder.

Aggiunta della libreria runtime RMI Access Builder al proprio spazio di lavoro
E' necessario importare la libreria runtime RMI Access Builder dalla Versione 3.0x di VisualAge per Java e aggiungerla al proprio spazio di lavoro. Non è possibile eseguire le applicazioni RMI Access Builder in VisualAge per Java, Versione 4.0 se non si esegue questa aggiunta.

  1. Selezionare File > Importa. 
  2. Selezionare il pulsante a selezione ciclica File Jar. 
  3. Immettere percorso e nome del run-time, che è x:\IBMJava\eab\runtime\ivjrmi.zip, dove x:\IBMJava indica la directory di installazione della Versione 3.0x.
  4. Selezionare la casella di spunta .class. Se la casella di spunta delle risorse è selezionata, deselezionarla. 
  5. Nel campo Progetto, digitare IBM Enterprise RMI Access Builder Library.
  6. Fare clic su Fine. 
  7. Se il progetto IBM Enterprise RMI Access Builder Libary non esiste ancora, verrà richiesto all'utente di crearlo.
  8. Assicurarsi che il progetto venga aggiunto allo spazio di lavoro. Se non compare sullo spazio di lavoro, andare all'Explorer del magazzino e selezionarlo per l'aggiunta.

Migrazione delle applicazioni RMI
Se le applicazioni RMI non si trovano già nel magazzino della Versione 4.0, seguire i passi riportati di seguito per importarli nello spazio di lavoro.

  1. Eseguire la versione delle classi e dei progetti di librerie runtime RMI Access Builder nella vecchia versione di VisualAge per Java. Se si desidera, è possibile conservare le classi semplicemente come classi .java. 
  2. Importarle nell'IDE di VisualAge per Java, Versione 4.0 seguendo questi passi:

Se si desidera eseguire gli oggetti server, è prima necessario creare una direttiva del server. Ad esempio, se si ha un proxy server del server: Reverse1S e ServerObj2S, è possibile scrivere una direttiva server per eseguire l'istanza degli oggetti server:

import...;
public class Servermain {
    public static void main(String arg[]) {
        try{
            Reverse1S myserver = new Reverse1S();
            ServerOvj2S obj2 = new ServerObj2S();
}
catch (Exception e) {
    e.printStackTrace();
    }
System.out.print ln("Server Objects Started.");
    }
}

Allo stesso modo, a causa di restrizioni di sicurezza, sarà necessario definire un file di regole per server e client. Ad esempio, si può avere un file di regole denominato "My policy":

grant {
//Concedere tutte le autorizzazioni
permission java.security.AllPermission;
};

Oppure consentire a chiunque l'ascolto su porte non privilegiate:

grant { 
// consente a tutti l'ascolto su porte non privilegiate
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.net.SocketPermission "localhost:1024-", "resolve"; 
permission java.net.SocketPermission "pathfinder:1000-4000", "listen";
permission java.net.SocketPermission "pathfinder:1000-4000", "connect";
permission java.net.SocketPermission "pathfinder:1000-4000", "resolve";
};

dove pathfinder indica il nome della macchina dell'utente.

Quando si avvia il proprio client, sarà necessario eseguire un comando simile a quello descritto di seguito per avviare il client in modo corretto:

java-Djava.security.policy=<myPolicy.file> 

Ad esempio, se si sta eseguendo main() dall'IDE, specificare java.security.policy= nella sezione Proprietà quando si seleziona la voce di menu "Esegui con".

E' possibile conservare la propria codifica sulla precedente versione di VisualAge per Java in modo da poter continuare lo sviluppo oppure rigenerarla.

D.16.0 Editor di composizione visiva (VCE)

E' necessario utilizzare lo strumento di migrazione dell'IDE per riparare metadati per composti visivi. Fare riferimento agli argomenti dell'aiuto in linea "Direttive di Correzione/Migrazione per riferimenti di classi o pacchetti" per informazioni su come riparare riferimenti di classi o pacchetti danneggiati a causa della migrazione di classi in J2SDK v.1.2.2 o per la ridenominazione di elementi di programma definiti dall'utente.

VisualAge per Java non conserva traccia delle dipendenze tra classi che vengono migrate. Le classi referenziate in una classe e che non sono ancora state migrate possono riscontrare problemi con l'inizializzazione oppure l'introspezione potrebbe essere non corretta.

Qualsiasi errore che si verifica durante la migrazione verrà registrato nella finestra Registrazione. Ad esempio, su supponga che il seguente messaggio venga visualizzato nella finestra Registrazione mentre si sta migrando una classe denominata Sample.Samp:

Migrazione classe: Sample.Samp

Impossibile migrare la classe:<Pkg>X::Y

Sample.Samp fa riferimento a X::Y; VisualAge per Java ha incontrato problemi nel caricamento della classe Y. Y non è stata migrata oppure è mancante. (Nell'Editor di composizione visiva, la classe Y appare come classe con problemi.) Per la correzione del problema, migrare Y oppure, se è mancante, trovare una classe di sostituzione per Y. In casi estremi, si può aprire Samp o Y nella precedente versione di VisualAge per Java e reimpostare i bean o le proprietà in modo che la migrazione possa continuare.

In alcuni casi, l'apertura della classe nell'Editor di composizione visiva (VCE) provoca l'apertura della finestra di dialogo Risolvi riferimenti di classe. Questa finestra di dialogo visualizza le classi con problemi presenti nel VCE. La colonna Riferimenti di classi non risolti della finestra di dialogo specifica la classe che VisualAge per Java utilizza come sostituzione temporanea. Ciò appare come illustrato di seguito:

com.ibm.uvm.abt.edit.DeletedClassView(X)

La X che appare tra parentesi è il nome della classe con problemi. E' probabile che X era stata migrata correttamente dopo la classe corrente. Per la correzione, selezionare la riga interessata e fare clic sul pulsante Sostituisci. Nella finestra di dialogo "Scegli una classe valida", selezionare la classe X come classe di sostituzione. Eseguire questa operazione per tutte le classi non risolte e, quindi, fare clic su OK.

D.17.0 Servlet Builder e Servlet Launcher

Servlet Builder e Servlet Launcher non sono inclusi in VisualAge per Java, Versione 4.0. Un file JAR runtime Servlet Builder compatibile con la Versione 4.0 è disponibile sul sito http://www.ibm.com/vadd. Seguire il collegamento ipertestuale "Download". 

Non esiste alcuna nuova funzione in VisualAge per Java, Versione 4.0 che sostituisce direttamente la funzionalità precedentemente fornita da Servlet Launcher.  Per testare i propri servlet, è possibile avviarli esplicitamente immettendo l'URL in un browser web, oppure scrivendo pagine HTML o JSP per richiamarli. Per lo sviluppo di nuovi servlet, è possibile utilizzare la nuova SmartGuide Servlet, che consente anche di creare una pagina HTML che avvierà il servlet.

Sono disponibili due opzioni per l'utilizzo del file runtime:

Scenario 1

In questo scenario, editare la codifica nella edizione precedente di VisualAge per Java, utilizzando il Servlet Builder prima di esportarla. 

  1. Esportare la codifica dell'applicazione dalla precedente versione di VisualAge per Java in una directory o in un magazzino al di fuori della struttura di installazione. 
  2. Utilizzare un programma di utilità come "Utility+ JDK Standard Edition" WoodenChair per migrare la codifica java (ridenominare pacchetti, gestire modifiche nelle dipendenze, etc.) in J2SDK v1.2.2. Per ulteriori informazioni relative a questo prodotto, andare al sito web WoodenChair, http://www.woodenchair.com/
  3. Compilare ogni file di classe .java e i file JAR utilizzando J2SDK v1.2.2. Il file JAR runtime Servlet Builder 4.0 deve trovarsi nel percorso di classe di compilazione. 
  4. Configurare la propria codifica nel Websphere Application Server. Il file JAR runtime Servlet Builder 4.0 deve trovarsi nella directory root del documento WebSphere Application Server oppure nel percorso di classe del server.
  5. Se è necessario apportare altre modifiche, ritornare al passo 1 e ripetere gli altri passi.

Scenario 2

In questo scenario, l'utente edita la codifica Servlet Builder all'interno di VisualAge per Java e la verifica in WebSphere Unit Test Environment.

Seguire questi passi:

  1. Importare il file JAR runtime Servlet Builder 4.0 in VisualAge per Java, Versione 4.0.
  2. Importare il progetto da gestire nello spazio di lavoro di VisualAge per Java, Versione 4.0.
  3. Utilizzare la SmartGuide Correzione/Migrazione per riparare i riferimenti danneggiati nella codifica.
  4. Modificare manualmente la codifica, compilarla e verificarla all'interno di WebSphere Unit Test Environment.
  5. Esportare il progetto in un file JAR.
  6. Configurare la propria codifica nel Websphere Application Server. Il file JAR runtime Servlet Builder 4.0 deve trovarsi nella directory root del documento WebSphere Application Server oppure nel percorso di classe del server.

Ulteriori informazioni sull'esecuzione di questi passi sono reperibili nell'aiuto in linea di VisualAge per Java.

La funzione Servlet Builder, disponibile in precedenti rilasci di VisualAge per Java, permetteva di creare servlet che generavano direttamente un'interfaccia utente HTML. Questa capacità è utile per lo sviluppo rapido di applicazioni, ma arretrata poiché combina la logica business dell'applicazione con la rispettiva interfaccia utente. Quindi, se si desidera modificare l'interfaccia utente, deve essere modificato il servlet. Per rendere più semplice la manutenzione, è preferibile utilizzare la tecnologia JavaServer Pages (TM) (JSP), per separare l'interfaccia utente dalla logica business.

Una pagina JSP è una maschera HTML che include contenuti generati in modo dinamico. Una pagina JSP può essere modificata utilizzando strumenti di editazione HTML come PageDesigner in IBM WebSphere Studio. Nel modello di programmazione WebSphere IBM, i servlet vengono utilizzati per interazione web, ma delegano la logica business a bean Java e l'interfaccia utente a JSP. In questo modello di programmazione, i servlet e i bean vengono sviluppati utilizzando strumenti Java e le pagine JSP vengono sviluppate utilizzando strumenti HTML.

Questa separazione della logica business e dell'interfaccia utente consente di assegnare responsabilità di sviluppo a membri del team in possesso di preparazione e strumenti appropriati, consentendo una più facile manutenzione.

In conformità con il modello di programmazione WebSphere, la funzione che era fornita da Servlet Builder è stata sostituita da strumenti Java in VisualAge per Java e da strumenti HTML in WebSphere Studio. VisualAge per Java, Versione 4.0 fornisce una nuova SmartGuide (wizard) per iniziare la creazione di applicazioni web che seguono il modello WebSphere. E' possibile utilizzare la SmartGuide Crea servlet per generare un servlet che richiama un bean per la logica business e una pagina JSP per l'interfaccia utente. La SmartGuide genera anche un modulo HTML che è possibile utilizzare per il test del servlet. Il servlet può essere immediatamente verificato nell'ambiente test WebSphere di VisualAge per Java e, quindi, rifinito nell'IDE. I file JSP e HTML possono essere ulteriormente editati utilizzando WebSphere Studio o un altro strumento HTML.

La SmartGuide Crea servlet è modellata sul wizard JavaBean in WebSphere Studio. Include inoltre, funzioni aggiuntive richieste dai programmatori Java. Se già si utilizza WebSphere Studio per lo sviluppo HTML, la SmartGuide semplificherà il flusso di lavoro tra tale strumento e VisualAge per Java. I passi di sviluppo sono i seguenti:

  1. Creare un Javabean per la logica business dell'applicazione.
  2. Eseguire la SmartGuide per generare servlet, JSP e modulo HTML.
  3. Verificare il servlet in VisualAge per Java
  4. Continuare lo sviluppo del servlet in VisualAge per Java.
  5. Rifinire i file JSP e HTML in WebSphere Studio o in uno strumento equivalente. 

D.18.0 Classi Swing

Le classi Swing si trovano in un diverso pacchetto in J2SDK v1.2.2 rispetto all'ubicazione che avevano in JDK v1.1.x. Se si desidera aggiornare i riferimenti alle classi swing, è possibile utilizzare la SmartGuide Correzione/Migrazione.

Per migrare le proprie applicazioni, è necessario selezionare le classi e i pacchetti interessati, aprire la SmartGuide Correzione/Migrazione (mediante clic con il tastino destro del mouse sul pacchetto o sulla classe e selezionando Riorganizza > Correggi/Migra), e selezionando la casella di spunta Includi pacchetti ridenominati JDK1.2 per migrare automaticamente i riferimenti Swing a J2SDK v1.2.2. In questo modo verranno aggiunte le voci appropriate Da/A per Swing. Qualsiasi errore che si verifica durante la migrazione verrà registrato nella finestra Registrazione. 

Fare riferimento agli argomenti dell'aiuto in linea:"Direttive di Correzione/Migrazione per riferimenti di classi o pacchetti" e "Ripristino di riferimenti di classi o pacchetti" per informazioni sulla corretta migrazione delle proprie applicazioni.  

Potrebbe non essere possibile utilizzare l'Editor di composizione visiva per migrare tutte le proprietà Swing da JDK 1.1.7 a Java 2 poiché la serializzazione cambia tra la Versione 1.03 e 1.1.1 di Swing. Dopo aver migrato la codifica in VisualAge per Java, Versione 4.0, potrebbe non essere possibile aprire alcune classi di applicazioni Swing nel VCE. Ciò si verificherà solo quando è stato utilizzato il foglio delle proprietà VCE per impostare le proprietà di un Javabean in un oggetto Swing.

Per evitare questo problema:

  1. Aprire nuovamente la classe nella precedente versione di VisualAge per Java (nel VCE).
  2. Nel foglio delle proprietà della classe, fare clic sul pulsante Reimposta. Viene aperta una finestra che elenca tutte le proprietà del bean che sono state modificate. Qualsiasi proprietà che è stata impostata negli oggetti Swing dovrebbe essere reimpostata sulle impostazioni di default.
  3. Salvare la classe e reimportarla nell'IDE della Versione 4.0.

D.19.0 XMI Toolkit  

Per informazioni sulla migrazione dalla versione Beta 1.2 di XMI Toolkit, fare riferimento alle note di rilascio XMI Toolkit.

Se è stato utilizzato un qualsiasi altro rilascio di XMI Toolkit diverso dalla Versione 3.5 (ad esempio, un'anteprima tecnologica, un rilascio alphaWorks o una versione Beta precedente), disinstallarlo e rimuovere gli aggiornamenti di ambiente eseguiti durante l'installazione prima dell'utilizzo di questo rilascio di XMI Toolkit. Le istruzioni sulla migrazione sono fornite solo per il Rilascio 1.2.

I file zip e i file XMI generati dai release Beta 1.2 e pre-Beta 1.2 non sono compatibili con alcun release 3.5 o 3.5.x di XMI Toolkit.

Parte E: Informazioni generali

E.1.0 Rapporto tra risorse del progetto e gestione risorse

Nella Versione 4.0 di VisualAge per Java, è ora possibile eseguire la versione e rilasciare i file di risorse del progetto. Per informazioni su questa nuova funzione, fare riferimento all'aiuto in linea relativo al team e all'IDE.

Se sono stati migrati progetti dalla Versione 2.0 o 3.0x di VisualAge per Java alla Versione 4.0, è possibile seguire i passi riportati di seguito, dopo aver completato il processo di migrazione. Non è necessario eseguirli immediatamente dopo la migrazione, ma fino a quando tale operazione non viene eseguita, nel magazzino non saranno presenti le versioni delle risorse di progetto. 
Nota: Non è necessario eseguire questi passi se i progetti sono stati migrati dalla Versione 3.5.

  1. Assicurarsi di aver copiato tutte le vecchie risorse di progetto nella directory delle risorse di progetto della Versione 4.0.
  2. Aggiungere i progetti allo spazio di lavoro dal magazzino.
  3. Creare una nuova edizione aperta di ciascun progetto. Non è possibile aggiungere nuove risorse al proprio progetto fino a quando non si crea un'edizione aperta dello stesso.
  4. Eseguire la versione del progetto, che rilascia tutte le risorse. 

Se si decide di lavorare in un ambiente team con l'Edizione Enterprise di VisualAge per Java, è necessario utilizzare EMSRV, Versione 7.1. 

E.2.0 Migrazione da OS/2 e AIX

OS/2 e AIX non sono supportati come piattaforme di sviluppo per VisualAge per Java, Versione 4.0. E' possibile installare VisualAge per Java, Versione 4.0 solo come client su Windows NT, Windows 98 e Windows 2000. Se si desidera utilizzare la Versione 4.0 con il proprio magazzino OS/2 e AIX, è necessario collegarsi a tale magazzino dall'IDE della Versione 4.0. Per eseguire questa operazione, fare riferimento all'aiuto in linea. 

Se è stata scritta codifica specifica per piattaforma, sarà necessario riscriverla perché possa funzionare su Windows.

Due scenari 

Nota: Non è possibile avere AIX e Windows sulla stessa macchina; i passi contenuti nello Scenario 1 sono applicabili solo per OS/2.

Scenario 1

Se il magazzino ivj.dat OS/2 si trova sulla stessa macchina del client Windows:

  1. Eseguire il backup del vecchio file ivj.dat. Il magazzino verrà ripristinato successivamente, dopo l'installazione di Windows 98, Windows NT o Windows 2000 e di VisualAge per Java, Versione 4.0. Se il magazzino è ubicato su una partizione FAT gestita da OS/2 e si decide di installare Windows 98/NT/2000 sulla stessa macchina conservando la partizione FAT, non è necessario eseguire il backup del magazzino. Si raccomanda, tuttavia, di eseguirlo nel caso si verificassero problemi quando si installa Windows. 
  2. Installare Windows 98, Windows NT o Windows 2000. Se la macchina esegue OS/2, Windows può essere installato sulla stessa macchina utilizzando l'opzione dual-boot per conservare l'installazione OS/2 esistente. 
  3. Installare VisualAge per Java, Versione 4.0. 
  4. Ripristinare il magazzino in una partizione su un disco fisso locale accessibile dalla nuova installazione Windows. Se in precedenza il magazzino era ubicato su una partizione FAT gestita da OS/2 e tale partizione è ancora presente, non sarà necessario ripristinare il magazzino. 
  5. Collegarsi al proprio vecchio magazzino (Enterprise) o importare dal proprio vecchio magazzino (Professional). Ricopiare tutte le vecchie risorse di progetto con quelle della directory di risorse di progetto Versione 4.0.

Scenario 2

Se il magazzino ivj.dat OS/2 o AIX si trova su una macchina diversa da quella del client Windows:

  1. La macchina OS/2 o AIX deve eseguire il programma di magazzino EMSRV (Versione 7.1) fornito con VisualAge per Java, Versione 4.0. E' possibile collegarsi a magazzini utilizzati con una Versione 3.02 o precedente di VisualAge per Java, ma è necessario disporre della Versione 7.1 di EMSRV installata per potersi collegare a un vecchio magazzino dalla Versione 4.0.
  2. Il client Windows, su cui si esegue VisualAge per Java, Versione 4.0 si collega al server OS/2 o AIX come richiesto. Ricopiare tutte le vecchie risorse di progetto con quelle della directory di risorse di progetto Versione 4.0.

E.3.0 Nuove restrizioni di sicurezza in J2SDK v1.2.2  

A causa di una modifica della sicurezza relativa agli applet in esecuzione sulla piattaforma Java 2 v1.2.2, gli applet non possono più accedere alle risorse locali. 

Alcuni esempi disponibili con versioni precedenti di VisualAge per Java non sono compresi in VisualAge per Java, Versione 4.0 a causa di tale restrizione. Inoltre, alcuni esempi inclusi possono essere eseguiti solo come applicazioni, altrimenti non funzioneranno correttamente. Fare riferimento alla documentazione in linea per le istruzioni sulla corretta esecuzione di questi esempi.

E' possibile modificare le regole di sicurezza di default creando il proprio file java.policy ed avviando il Viewer applet con il seguente parametro: -Djava.security.policy=someURL

dove someURL indica l'ubicazione del nuovo file delle regole. Per ulteriori dettagli sulla sicurezza generale in Java, fare riferimento a http://java.sun.com/security. Per informazioni specifiche sulla sicurezza in Java 2 e sulla sintassi dei file delle regole, fare riferimento a http://java.sun.com/products/jdk/1.2/docs/guide/security

E.4.0 Nuovo strumento di controllo versione esterno (sostituisce lo strumento SCM External)

Il nuovo strumento Controllo versione esterno introdotto in VisualAge per Java, Versione 3.5.3 consente di collegarsi a fornitori SCM (source code management) esterni, quali ClearCase, PVCS Version Manager, TeamConnection(TM) e SourceSafe(TM) da VisualAge per Java. Con questo strumento è possibile aggiungere classi al proprio fornitore SCM, verificare classi e file di risorse dal sistema SCM ed importare la più recente versione di una classe dal sistema SCM.

Questo strumento sostituisce il vecchio strumento SCM External e offre una maggior funzionalità.

E. 5.0 Gestione di ORB di terzi in VisualAge per Java

E' possibile gestire Object Request Brokers (ORB) di terzi in VisualAge per Java se questi sono compatibili con J2SDK v1.2.2. Prima di poterle utilizzare, è necessario importare le classi ORB nell'IDE.

Quando si importano classi Java nell'IDE, è possibile aggiungere classi di estensione ORB alle librerie di classi Java. E' anche possibile sostituire alcune classi di estensione ORB situate nelle librerie di classi Java esistenti poichè non fanno parte delle classi principali di J2SDK v1.2.2.

Un articolo contenente ulteriori dettagli sulla gestione di ORB di terzi nella Versione 3.5.x è reperibile dal sito web:

http://www.ibm.com/software/vadd/Data/Document2175

Tale articolo contiene informazioni esaurienti sullo sviluppo di applicazioni CORBA (Common Object Request Broker Architecture) e ORB in VisualAge per Java.

Alcune classi di librerie java potrebbero essere sostituite quando un ORB di terzi viene importato in VisualAge per Java. La Patch 2 per la Versione 3.5 corregge un errore che consentiva erroneamente all'utente di importare alcune classi immutabili (quelle contenute in pacchetti mutabili) in VisualAge per Java. Dopo l'applicazione della Patch 2 a VisualAge per Java, Versione 3.5, si potrebbero ricevere avvertenze nuove o aggiuntive nella finestra Registrazione quando si importa un ORB di terzi. Queste avvertenze vengono visualizzate perchè non è possibile importare classi immutabili in VisualAge per Java dopo l'applicazione della Patch 2, ma è possibile ignorarle.

E.6.0 Contenuto del CD Funzioni aggiuntive

Il CD Funzioni aggiuntive di VisualAge per Java contiene quanto riportato di seguito:

La Guida all'installazione e alla migrazione e il README del prodotto si trovano sul CD Funzioni aggiuntive e anche sul CD principale del prodotto.

Nota: Il CD Funzioni aggiuntive è incluso solo in VisualAge per Java, Edizione Enterprise. Le seguenti voci, comunque, sono incluse sul CD del prodotto di VisualAge per Java, Edizione Professional:

La Guida all'installazione e alla migrazione e il README del prodotto si trovano sul CD del prodotto di VisualAge per Java, Edizione Professional.

IBM J2EE Connector e Tool per J2EE(TM) - Beta

Questo release di VisualAge per Java include una versione beta di vari componenti della piattaforma Java 2, Enterprise Edition (J2EE) non ufficialmente rilasciati dalla Sun Microsystems Inc. Si tratta dei seguenti componenti:

I componenti beta sono ubicati nella directory secondaria extras\BetaJ2EEConnectors. Se si desidera utilizzare questi componenti beta, fare riferimento al file README nella directory secondaria BetaJ2EEConnectors contenente istruzioni di installazione relative ai componenti.

Nota: I componenti forniti con VisualAge per Java, Versione 4.0 sono supportati solo su Windows NT e Windows 2000. Non tutti i file runtime J2EE sono supportati su Windows 2000. Per ulteriori informazioni sui componenti J2EE, fare riferimento all'aiuto in linea e alle note di rilascio di Enterprise Access Beans.

Team Server (EMSRV) 

La directory TeamServer sul CD Funzioni aggiuntive contiene il programma server del magazzino EMSRV e il file di "Impostazione e gestione del server" (emsrv71.htm o emsrv70.htm per tutte le lingue diverse dall'inglese). Per istruzioni sull'installazione di EMSRV, fare riferimento alla Parte C; per informazioni sull'avvio del server, fare riferimento al file di  "Impostazione e gestione del server" (ubicato in TeamServer\docs). 

Runtime distribuibili

Quando si esporta e si configura un applet o un'applicazione creata con VisualAge per Java, è anche necessario configurare la libreria runtime per le funzioni con le quali è stata creata la codifica e inserire il file JAR o il file Zip runtime configurato nel proprio percorso di classe.

In generale, i file JAR sono compressi e sono utilizzati durante l'esecuzione di applet al di fuori del server. I file Zip sono decompressi e dovrebbero essere sistemati sul CLASSPATH della macchina di configurazione per l'esecuzione locale di applicazioni.

Le librerie runtime VisualAge per Java sono contenute nelle directory extras/runtime30 e extras/runtime35. In base alla funzione VisualAge per Java che è stata installata, alcune o tutte le librerie runtime vengono anche fornite nella directory eab/runtime35 o runtime30 della propria immagine di installazione. Nota: Le librerie runtime J2EE non sono comprese nel CD Funzioni aggiuntive. I file runtime per i connector J2EE verranno sistemati in eab\runtime 35 e IBM Connectors\classes dopo aver installato i componenti beta.  

Per ulteriori informazioni sull'installazione e il riutilizzo di librerie runtime, fare riferimento all'aiuto in linea.

IBM Developer Kit 1.2.2 (per Windows)

IBM Developer Kit, Java Technology Edition, v 1.2.2, PTF 9, ubicato nella directory IBM Developer Kit, è un ambiente di sviluppo Java che aiuta nello sviluppo di applet e applicazioni Java autonome conformi al 100% alla specifica Pure Java.

Include strumenti per lo sviluppo di applicazioni e applet Java, tra cui: 

Java Compiler 
Converte codifica di origine Java in codifiche di byte Java che successivamente possono essere eseguite mediante Java Interpreter.
Librerie di classe Java 
Forniscono tutte le classi Java standard, consentendo alle applicazioni Java di creare ed estendere oggetti Java esistenti. 
Viewer applet Java 
Fornisce un sistema per eseguire un applet da un prompt di comandi. 
Generator di documentazione Java 
Genera la documentazione dell'API (Application Programming Interface) Toolkit da programmi Java commentati. 

Per installare IBM Developer Kit, eseguire install.exe dalla directory IBM Developer Kit. Per informazioni dettagliate su IBM Developer Kit, fare riferimento al file README nella directory IBM Developer Kit.

Merant DataDirect SequeLink Java Edition Versione 5.1 per Oracle e Microsoft SQLServer

VisualAge per Java, Versione 4.0 supporta il driver DataDirect SequeLink Java Edition Versione 5.1 Merant per l'accesso a Microsoft SQL Server e al database Oracle.

Nota: il server DataDirect SequeLink Java Edition Versione 5.1 Merant distribuito con VisualAge per Java, Versione 4.0 è supportato solo su Windows NT e Windows 2000.

SequeLink è un componente per l'accesso ai dati middle-ware che fornisce le capacità di connessione dei dati per gli ultimi standard JDBC a una serie di database come Oracle, Microsoft SQL server e a dati mainframe. Il componente client SequeLink è indipendente da database; quindi non è necessaria alcuna modifica se vengono aggiunti nuovi database all'infrastruttura. Un client SequeLink specifico viene fornito con WebSphere Test Environment.

Nota: Dato che il client SequeLink è specifico, è possibile comunicare con il server DataDirect Sequelink Java Edition Versione 5.1 Merant solo mentre si utilizza il client insieme a WebSphere Test Environment oppure a Websphere Application Server. Il server DataDirect Sequelink Java Edition Versione 5.1 Merant non è un server con licenza completa; non è quindi possibile utilizzarlo per scopi diversi dalla gestione del client Sequelink fornito. Se si dispone di un server DataDirect Sequelink Java Edition Versione 5.1 Merant con licenza completa, il client Sequelink funzionerà anche con questo.

Il server SequeLink corrispondente è disponibile per un'installazione senza chiave (cioé, non verrà richiesta una chiave di registrazione per installarlo). Il server può essere installato dalla directory secondaria Merant\SequeLinkServer dal CD Funzioni aggiuntive.

L'impostazione e l'installazione del driver dipende dal componente con cui si intende utilizzalo. Fare riferimento alle seguenti note di rilascio per informazioni specifiche sull'impostazione e l'installazione (incluso informazioni sulla configurazione del client SequeLink fornito con WebSphere Test Environment):

Distributed Debugger

Se si intende sottoporre a debug qualsiasi classe sviluppata al di fuori dell'IDE di VisualAge per Java oppure programmi in esecuzione su una diversa macchina, è necessario installare Distributed Debugger.

Distributed Debugger è supportato sui seguenti sistemi operativi: Windows, AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. Tutti i file del debugger si trovano nella directory del debugger sul CD Funzioni aggiuntive. Fare riferimento alla Parte B, Sezione 2.1.1.1. per le istruzioni di installazione.  

Anteprime tecnologiche

Il CD Funzioni aggiuntive contiene due Anteprime tecnologiche: IBM Stored Procedure Integration Tool for Enterprise JavaBeans e XMI Bridge.

IBM Stored Procedure Integration Tool for Enterprise JavaBeans

E' possibile utilizzare IBM Stored Procedure Integration Tool for Enterprise JavaBeans (SP integration tool for EJB) per migliorare i propri EJB di sessione aggiungendo metodi che richiamano procedure memorizzate del database. Utilizzando la SmartGuide Crea metodo di richiamo di procedure memorizzate, è possibile definire i propri metodi e, quindi, generare il nuovo metodo nel bean di sessione privo di stato.

Utilizzando SP integration tool for EJB, è possibile allegerire la logica business contenuta nelle procedure memorizzate esistenti all'interno di un ambiente EJB. E' possibile ridurre al minimo lo sforzo per lo sviluppo EJB ed evitare logica business ridondante nel server EJB e nel database management system (DBMS). Inoltre, poiché le procedure memorizzate possono ridurre il traffico di rete tra server EJB e DBMS, è possibile aumentare le prestazioni delle proprie applicazioni di produzione.

SP integration tool for EJB si trova nella directory secondaria extras\spt. Per ulteriori informazioni sull'installazione e l'utilizzo dell'anteprima tecnologica, fare riferimento al file EJB_SPTool.PDF nella directory spt. Dopo aver installato SP integration tool for EJB, il file EJB_SPTool.PDF verrà ubicato anche nella seguente directory: x:\ibmvjava\ide\tools\com-ibm-ivj-sptools, dove x:\ibmvjava indica la directory di installazione del prodotto.

XMI bridge

XMI bridge è un'anteprima tecnologica per Persistence Builder e Enterprise Java Beans che consente di importare un file di modello Rational Rose o un documento XMI in un modello Persistence Builder oppure in un gruppo EJB.

XMI bridge si trova nella directiry extras\xmib. Prima di poter utilizzare XMI bridge, è necessario aver aggiunto XMI Toolkit allo spazio di lavoro. Per ulteriori informazioni sull'installazione e l'utilizzo dell'anteprima tecnologica, fare riferimento al file README nella directory xmib.

Documentazione stampabile

Alcune parti dell'aiuto in linea sono state raccolte in documenti PDF che è possibile visualizzare e stampare utilizzando Adobe Acrobat Reader (disponibile su http://www.adobe.com/). Non tutti i PDF sono disponibili in tutte le lingue. I file PDF sono disponibili dalla directory pdf. 

Per informazioni sul contenuto di ciascun file PDF, fare riferimento all'Indice PDF (nel manuale Guida introduttiva).

Guida alla risoluzione dei problemi del sistema di aiuto

Per informazioni sul ripristino da malfunzionamenti dell'aiuto, fare riferimento alla guida per la risoluzione dei problemi del sistema di aiuto. Tale guida si trova nella directory Troubleshoot del CD Funzioni aggiuntive ed è disponibile in tutte le lingue.

Magazzino e risorse

La directory ivj40 contiene due file zip: ide.zip e wte_resources.zip. Il file ide.zip contiene una copia del magazzino (ivj.dat), la directory delle risorse di progetto (ivj.dat.pr) e il file di spazio di lavoro (ide.icx). Il file wte_resources.zip contiene una copia di backup delle risorse di progetto per la funzione WTE.

Appendice A: Confronto tra componenti di accesso dati 

Di seguito viene fornito un confronto tra Data Access Builder, Bean Data Access e Persistence Builder. E' inclusa una breve descrizione dell'Ambiente di sviluppo EJB, ma questo componente non viene trattato nel confronto.

La funzione Bean Data Access offre uno strumento rapido per accedere visivamente a dati relazionali. Questa funzione viene utilizzata con applicazioni in cui non è richiesto un modello di oggetto riutilizzabile. E' possibile utilizzare i Bean Data Access per creare applicazioni visive che hanno bisogno di una vista diretta delle tabelle all'interno del database di destinazione. E' anche possibile incorporare manualmente i Bean Data Access nella propria codifica.

L'Ambiente di sviluppo EJB consente di sviluppare bean che implementano le specifiche di programmazione Enterprise JavaBeans (EJB) di Sun Microsystems. L'ambiente di sviluppo EJB fornisce tutto il supporto runtime necessario a IBM WebSphere Application Server. Un programma di verifica della coerenza ad incremento assicura la conformità dei bean enterprise alla specifica di programmazione EJB e indica se sono necessarie modifiche per correggere le incongruenze. Per ulteriori informazioni sull'Ambiente di sviluppo EJB, fare riferimento all'aiuto in linea.

Il Persistence Builder fornisce un supporto di persistenza scalabile per modelli di oggetti e rappresenta per molti utenti il primo passo verso EJB.Le applicazioni costruite utilizzando Persistence Builder possono indirizzarsi al modello di oggetto riutilizzabile ottimale e associarlo rapidamente a qualsiasi database relazionale supportato. Persistence Builder supporta associazioni dal basso verso l'alto (Schema-Oggetto) e viceversa (Oggetto-Schema). Questa funzione associa oggetti e relazioni tra oggetti ai dati memorizzati in database relazionali.

Il resto di questo documento descrive le differenze tra le funzioni di accesso ai dati - Bean Data Access, Data Access Builder e Persistence Builder.

I dettagli sull'implementazione per ciascuna funzione non sono trattati. La documentazione in linea tratta la funzionalità aggiuntiva offerta da Persistence Builder e bean Data Access, come le relazioni, gli elementi della tavolozza visiva, le capacità di transazioni avanzate e la SmartGuide SQL Assist.

L'elenco delle funzioni fondamentali riportato di seguito rappresenta una panoramica delle principali capacità di Data Access Builder. Ogni funzione principale è stata implementata in modo diverso da ciascun componente.

Parte 1: Funzioni di associazione Oggetto-Relazionale

Associazione Schema-Oggetto di database

Creazione della codifica

Parte 2: Funzioni runtime

Parte 3: Funzioni Bean Data Access

Le implementazioni delle funzioni sono descritte nelle pagine seguenti. Le funzioni Data Access Builder e Persistence Builder vengono tutte confrontate consecutivamente, mentre le funzioni Bean Data Access comparabili (per l'associazione) sono elencate alla fine di questa sezione.

Parte 1: Funzioni di associazione Oggetto-Relazionale

Associazione Schema-Oggetto di database

1.0 Associazione Schema-Oggetto di database mediante tabelle e viste

In Data Access Builder

Nota: Tutti i passi del Data Access Builder devono essere eseguiti in una precedente versione di VisualAge per Java (3.02 o precedente) che include il Data Access Builder. 

Nella SmartGuide Associa schema, selezionare il collegamento DB2 o ODBC, quindi selezionare il pulsante a selezione ciclica Seleziona tabelle o vista database. Fare clic su Avanti. Viene aperta la seguente pagina, contenente un elenco di tabelle:

Selezionare le tabelle da gestire e fare clic su Fine. Verranno create associazioni di oggetti 1 a 1 tra queste tabelle e gli oggetti risultanti. La finestra Data Access Builder mostra la colonna di attribuzione dell'associazione che si verifica automaticamente.

In Persistence Builder

Nel browser Schema, selezionare Schemi > Importa schema da database. Immettere le informazioni sul collegamento. Viene aperta la finestra di dialogo Selezione tabelle.

Selezionare le tabelle o le viste desiderate e fare clic su OK. Ora il browser di schema contiene il nuovo schema e ne elenca le relative tabelle, colonne e chiavi.

Selezionare Schemi > Genera modello da schema. In questo modo viene creato un semplice modello business one to one.

2.0 Associazione Schema-Oggetto di database mediante interrogazioni personali

In Data Access Builder

Nella SmartGuide Associa schema, selezionare il collegamento DB2 o ODBC, quindi selezionare il pulsante a selezione ciclica Immetti istruzione SQL. Fare clic su Avanti. Selezionare le tabelle da gestire e fare clic su Avanti. Viene aperta la seguente pagina:

Immettere la propria interrogazione e fare clic su Fine. L'esempio precedente mostra un'interrogazione di unione di due tabelle. Sono supportate anche interrogazioni con valori di parametri.

L'oggetto risultante contiene gli attributi di entrambe le tabelle, come illustrato di seguito:

In Persistence Builder

E' possibile utilizzare Persistence Builder per eseguire l'associazione di unione interrogazioni associando manualmente lo schema.
  1. Importare lo schema utilizzando il browser Schema.
  2. Aprire il browser del modello e creare il modello oggetto a cui le tabelle verranno associate.
  3. Una volta completato il modello, aprire il browser di mappa e creare una nuova mappa di datastore. Selezionare lo schema e il modello già creati.
  4. Selezionare una classe di modello ed aggiungere una mappa cluster selezionando Nuova mappa tabella > Aggiungi mappa cluster senza eredità.
  5. Per aggiungere altre tabelle di unione, selezionare Nuova mappa tabella > Aggiungi mappa tabella secondaria. Dopo aver aggiunto le tabelle, associare i singoli attributi aprendo l'editor mappa proprietà su ciascuna mappa di tabella.
  6. Associare ogni attributo alle colonne di tabelle, lasciando non associate le altre colonne di tabelle. Il browser di mappa visualizzerà le mappe di proprietà corrispondenti a ciascuna tabella nel quarto pannello.

3.0 Associazione Schema-Oggetto di database mediante procedure memorizzate

In Data Access Builder

Nella SmartGuide Associa schema, selezionare il collegamento DB2 o ODBC, quindi selezionare il pulsante a selezione ciclica Insieme di risultati di procedura memorizzata. Viene aperta la pagina Procedure memorizzate contenente un elenco di procedure memorizzate. Immettere un nome per l'associazione, selezionare la procedura memorizzata e fare clic su Fine.

L'oggetto risultante contiene attributi associati alla colonna di risultati della procedura memorizzata. Le interrogazioni o le procedure memorizzate per le operazioni CRUD non sono pre-definite per questo tipo di associazione.

In Persistence Builder

Persistence Builder non dispone di alcuno strumento che supporta l'associazione di procedure memorizzate. E' possibile generare uno "Schema matrice" che crea classi di servizio scheletro in cui l'utente deve fornire la codifica di supporto. Il metodo per tutte le istanze dovrebbe apparire come illustrato di seguito:

/**
* Return a query spec for the query called allInstances
* @return java.util.Vector
*/

public java.util.Vector allInstancesQuery() {
   Vector aSpecArray = new Vector();
     DatabaseCompoundType aCompoundType;
        DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call getAllEmp ()}");
      aCompoundType = new DatabaseCompoundType();
        aCompoundType.addField((DatabaseTypeField)(new                              com.ibm.ivj.db.base.DatabaseDecimalField("COMM")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));

((DatabaseSelectQuerySpec)spec).setOutputShape(aCompoundType);

aSpecArray.addElement(spec);
return aSpecArray;
}

Creazione della codifica

 

4.0 Operazioni CRUD su oggetti

Data Access Builder

Le operazioni CRUD (Create, Retrieve, Update e Delete) di base vengono automaticamente generate con associazioni una tabella-un oggetto. Se si utilizzano interrogazioni personali o procedure memorizzate, queste interrogazioni vengono perse ed è necessario definirle manualmente utilizzando lo strumento Data Access Builder. Un esempio è rappresentato da un'interrogazione di unione che definisce un oggetto Customer.

  1. Nella finestra Data Access Builder, dal menu concatenato di un bean, selezionare Metodi. Aggiungere un nuovo metodo denominato addCustomer1.

  2. Immettere la seguente istruzione SQL:

INSERT INTO TPF.CUSTOMER (
CUSNO,
FIRSTNAME,
MIDINIT,
LASTNAME,
HOMEPHONE,
HOMEADDR,
WORKPHONE,
BILLADDR,
BRANCHNO,
OPEN DATE)
VALUES (?, ?, ?, ?, ?, ?, ?,?, ? ,?)

Dopo che Data Access Builder ha convalidato l'interrogazione, associare singolarmente i parametri utilizzando la pagina Parametro.

E' anche necessario definire l'interrogazione addCustomer2 per l'inserimento della seconda tabella di unione CUSTDATA. La sincronizzazione delle due interrogazioni per questa funzione viene gestita dall'utente.

Persistence Builder

Persistence Builder creerà tutte le operazioni CRUD una volta creata un'associazione tra lo schema e il modello definiti. In caso di unioni di tabelle multiple, viene generata un'interrogazione per ciascuna tabella e il motore di servizio gestisce tali operazioni come un'unica unità base.

Le procedure memorizzate non sono ancora supportate negli strumenti, ma è possibile generare ed estendere "Schemi matrice". Di seguito viene riportato un esempio di interrogazione di procedura memorizzata di inserimento.

/**
*Return a query spec for the query called insert
* @return java.util.Vector
* @param args java.util.Vector
* @param anInjector com.ibm.vap.Persistence.BOInjector 

public java.util.Vector insertQuery(java.util.Vector args,com.ibm.vap.Persistence.BOInjector anInjector) {
    Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
   

 DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call     

    insertEmp (?,?,?,?)}");

Vector stringArgs;
a CompoundType = new DatabaseCompoundType();

aCompoundType.addField((DatabaseTypeField)(new         com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));

aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));

StringArgs = new Vector();
stringArgs.addElement("EMPNO");
stringArgs.addElement("SAL");
stringArgs.addElement("DEPTNO");
stringArgs.addElement("ENAME");

spec.setInputShape(aCompoundType);
spec.setInputValues(args);
spec.setInputNamesWithDuplicates(stringArgs);
   aSpecArray.addElement(spec);
        return aSpecArray;

5.0 Supporto interrogazione personale

In Data Access Builder

Le interrogazioni personali nel Data Access Builder vengono definite nello stesso modo in cui sono definite le interrogazioni CRUD. L'utente aggiunge la determinata interrogazione e utilizza, se necessario, la pagina dei parametri. L'interrogazione risultante verrà visualizzata come metodo sulla classe BusinessObjectMgr.

Il Data Access Builder fornisce anche altri metodi di definizione di interrogazioni personali, come la sostituzione di SQL Predicate.

TheEmpMgr.select('WHERE WORKDEPT = 'E11');

In Persistence Builder

Esistono due opzioni per aggiungere interrogazioni personali in Persistence Builder. Raccolte Lite possono essere definite a livello di classe utilizzando l'editor di classi. La seguente pagina viene utilizzata per la ricerca e il filtro sulla classe specificata.

Le interrogazioni di raccolte lite vengono generalmente utilizzate in elenchi o finestra di ricerca per evidenziare l'adatto Business Object. I metodi risultanti restituiscono vettori di "Oggetti dati" che possono essere utilizzati per richiamare il corrispondente business object persistente.

Di seguito è riportato un esempio di codifica che utilizza la raccolta lite generata che è stata appena descritta:

VapCourseHomeImpl aHome = VapCourseHomeImpl.singleton();
    VapDepartmentKey aKey = new VapDepartmentKey("Sales"); 
VapLiteCollection liteCollection = aHome.getByDepartmentLiteCollection(aKey); 

Enumeration enum = liteCollection.elements();
VapCourseDataObject aDO;
VapCourse aCourse; 

while (enum.hasMoreElements()) {

    aDO = (VapCourseDataObject)enum.nextElement(); 
   aCourse = aHome.find(aDO.getNumber()); 
   //Fetching fully hydrated EJBObject
   }

Persistence Builder fornisce anche un framework di interrogazioni personali che può essere utilizzato per definire varie operazioni su una classe business. Tali interrogazioni restituiranno business object completamente funzionali.

Di seguito è riportato un esempio di una classe student con un'interrogazione personale "retrieveStudentsOver21". La classe principale per students ha il seguente metodo:

public Vector retrieveStudentsOver21() throws java.rmi.RemoteException,     
com.ibm.vap.common.VapReadFailureException {
    return customQuery("studentsOver21Query");
}

La QueryPool per students contiene i corrispondenti metodi per il servizio personale:

/* Restituire una specifica per l'interrogazione denominata studentsOver21
 @return java.util.Vector */

public java.util.Vector studentsOver21Query() {
    Vector aSpecArray = new Vector();
    aSpecArray.addElement(new DatabaseSelectQuerySpec(studentsOver21SqlString()));
          return aSpecArray;

}

/* Restituire la stringa SQL per l'interrogazione denominata studentsOver21Query
  @return java.lang.String */

public java.lang.String studentsOver21SqlString() {

return "SELECT T1.SNAME, T1.SNO, T1.SADVFNO, T1.SBDATE, T1.SADDR, T1.SPHNO, T1.SMAJ, T1.SIQ FROM SPARKY.STUDENT T1 WHERE T1.SBDATE <= (CURRENT DATE - 00210000.)";
}

Questo metodo viene eseguito da home e ha un comportamento di cache degli oggetti simile al metodo All-instances. Per ulteriori informazioni su questo metodo, fare riferimento all'aiuto in linea di Persistence Builder.

Parte 2: Funzioni runtime

1.0 Capacità Datastore/Transazionali

In Data Access Builder

I datastore in Data Access Builder possono essere configurati a diversi livelli applicativi:

I datastore Data Access Builder hanno un modello transazionale piatto, in altre parole, se sono necessarie più transazioni per applicare una funzione business, sarà necessario attivare un datastore che rappresenti ciascuna transazione.

Ecco un semplice scenario con un modello Employee e Department:

EmployeeDatastore anEmpDS = new EmployeeDatastore().connect();
DepartmentDatastore aDeptDS = new DepartmentDatastore().connect();

Employee anEmp = new Employee();
Department aDept = new Department();

// Perform actions on anEmp and aDept

if (User Applied Employee Changes)
anEmpDS.commit()
else
anEmpDS.rollback();
aDeptDS.commit();

Persistence Builder

In VisualAge per Java, Versione 4.0 Persistence Builder ha l'opzione di poter utilizzare il WebSphere Connection Pool mediante il nome JNDI per localizzare l'origine dei dati. Questa opzione è disponibile quando si creano le classi di servizio.

Più datastore in Persistence Builder sono richiesti solo se vengono utilizzati diversi database per accedere ai dati del modello. Le transazioni nidificate multiple sono supportate per datastore. Le transazioni non sono implicite come avviene in Data Access Builder. Le transazioni utente sono controllate da oggetti di transazione che dispongono di viste sui business object delle applicazioni.

Ecco un breve esempio di codifica che mostra la stessa capacità transazionale descritta nell'esempio relativo al Data Access Builder.

DB2Datastore aDS = DB2Datastore.singleton().activate();
Transaction empTransaction = Transaction.begin();
Employee anEmp = EmployeeHomeImpl.create("EmpNum1");
Transaction deptTransaction = Transaction.begin();
Department aDept = DepartmentHomeImpl.create("DeptNum1");

// Do some actions on anEmp and aDept, always resuming the appropriate transaction before making changes to the corresponding BO.

if (User Applied Employee Changes)
    empTransaction.commit();
else
    empTransaction.rollback();
deptTransaction.commit();

E' importante notare che in Persistence Builder, nessuna SQL viene eseguita fino al commit di una transazione. Lo stato transazionale degli oggetti viene mantenuto internamente fino a quando si verifica un rollback o un commit esplicito.

2.0 Supporto API

I metodi generati sui business object risultanti e gli oggetti di gestione associati sono leggermente diversi per i tre framework. La seguente tabella illustra le classi e i metodi utilizzati per ciascuna funzione.

 

Data Access Builder

Persistence Builder

Bean Data Access

Crea

aBusinessObject.add();

aBusinessObjectHome.create();

aSelectBean.newRow();

Richiama

aBusinessObject.retrieve();

aBusinessObjectHome.find (aKey);

 aSelectBean.setParameter
("ColumnName", value);
aSelectBean.execute();
Richiama tutti/e aBusinessObjectMgr.select(); aBusinessObjectHome.allInstances(); aSelectBean.execute();
Aggiorna aBusinessObject.update(); (*) Non supportato
Cancella aBusinessObject.delete(); aBusinessObject.remove(); Non supportato
Cancella corrente aBusinessObject.deleteCurrent(); Non supportato (**) aSelectBean.deleteRow();
Aggiorna corrente aBusinessObject.updateCurrent(); Non supportato (**) aSelectBean.updateRow();
Commit aBusinessObjectDS.commit(); currentTransaction.commit(); aSelectBean.commit();
Rollback aBusinessObjectDS.rollback(); currentTransaction.rollback(); aSelectBean.rollback();
Attiva aBusinessObjectDS.connect(); aDataStore.activate(); aSelectBean.connect();
Reimposta ABusinessObjectDS.disconnect(); aDataStore.reset(); aSelectBean.disconnect();

Esempio di codifica: Ricercare un impiegato e modificare il numero telefonico

Employee anEmp = 
new Employee();
anEmp.setEmpno
("000130");
anEmp.retrieve();
anEmp.setPhoneno
("555-9988");
anEmp.update();
anEmp.getDefault
Datastore().
commit();

EmployeeHome aHome = EmployeeHome.singleton();

Employee anEmp = 
aHome.find("000130");

anEmp.setPhoneno("555-9988");
Transaction.
getCurrent().commit();

Richiamare tutti gli impiegati:

aSelectBean.execute();

positionToEmployee
("000130"); 
// User written method
// to position to 
//correct row

aSelectBean.
setColumnValue
("PhoneNo", "555-9988");

aSelectBean.updateRow();

aSelectBean.commit();
// If connection is not
//autoCommit=true

Richiamare l'insieme di risultati con
una sola riga impiegati.

aSelectBean.setParameter
("EmployeeID", "000130");
aSelectBean.execute();
aSelectBean.setColumnValue
("PhoneNo", "555-9988");
aSelectBean.updateRow();

aSelectBean.commit();
// If connection is not 
//autoCommit=true

(*)Sono implicite operazioni di aggiornamento mediante la modifica dei valori su un business object; se viene eseguito il commit della transazione attiva, le modifiche verranno sincronizzate con il datastore mediante l'emissione delle appropriate istruzioni di aggiornamento.

(**)La sezione Supporto cursore illustra soluzioni alternative.

Supporto LOB

Data Access Builder

Persistence Builder

Bean Data Access

Data Access Builder include una classe denominata DAIOStream, che può essere utilizzata per richiamare LOB dal database, senza occupare la memoria con l'intero oggetto.

Persistence Builder attualmente non supporta LOB di flusso. Gli oggetti LOB vengono caricati nella memoria.

DAB supporta tipi di dati LOB JDBC 2.0. Se si sta utilizzando un driver JDBC 2.0 per richiamare un LOB, si ha la possibilità di richiamare l'intero LOB nella memoria o soltanto la sua ubicazione.
 

3.0 Quickform (Funzioni RAD)

Data Access Builder

Persistence Builder

Bean Data Access

La funzione di modulo rapido di Data Access Builder fornisce rapide visualizzazioni di esempio che utilizzano parti AWT comuni per rappresentare il modello fornito.

Una raccolta di parti visive sul VCE può essere utilizzata come aiuto nella programmazione visiva. Tali parti rappresentano classi transazionali che aiutano l'utente a separare visivamente le unità di lavoro.

La Versione 4.0 contiene un wizard per applicazioni di database che genera un'applicazione che utilizza componenti Swing per rappresentare le colonne di una tabella ottenuta da un bean Select. E' anche possibile utilizzare le capacità QuickForm standard del VCE per creare rapidamente una UI personale basata sulle proprietà di un bean Select.

4.0 Supporto Data/Ora/Timestamp corrente

Gli strumenti Data Access Builder consentono all'utente di specificare tipi di dati "correnti" per data/ora, e generare l'appropriata SQL. Persistence Builder e bean Data Access non supportano questa funzione nei rispettivi strumenti, ma la SQL può essere aggiunta manualmente.

5.0 Supporto cursore

Data Access Builder supporta funzioni di cursore su insiemi di risultati come updateCurrent() o deleteCurrent().

Persistence Builder non supporta attualmente queste operazioni. Un'alternativa consiste nell'utilizzare la funzione bean Data Access.

I Bean Data Access supportano funzioni di cursore con la parte visiva DBNavigator che gestisce la posizione del cursore. Di seguito viene riportata una descrizione di tutte le funzioni di cursore:

JDBC v1.0 non supporta lo scorrimento all'indietro in un insieme di risultati JDBC. Il bean Select mantiene una cache dell'insieme di risultati che consente di scorrere attraverso l'insieme e di accedere direttamente ad una riga specifica. Il bean Select dispone di proprietà che consentono all'utente di controllare le dimensioni della cache. E' possibile aprire l'intero insieme di risultati nella cache (valore di default), oppure aprire nella cache un pacchetto alla volta. La dimensione e il numero di pacchetti è controllata dall'utente.

Una volta ottenuto un insieme di risultati, il bean Select fornisce metodi per aggiornare, cancellare o inserire righe nell'insieme di risultati. Non è necessario che l'utente scriva alcuna nuova SQL per eseguire queste funzioni.

6.0 Esecuzione asincrona

Data Access Builder supporta operazioni asincrone fornendo interfacce eseguibili sulle relative classi generate.

Persistence Builder fornisce inoltre interfacce eseguibili per ciascuna operazione CRUD ed una per le interrogazioni personali. L'oggetto di servizio per ciascuna classe business ha il metodo runAsynch(), che determina il tipo di esecuzione per tale classe.

I Bean Data Access supportano l'esecuzione asincrona mediante lo strumento DBNavigator che estende istanze eseguibili "DBAction".

Risultati in conflitto (blocco/livelli di isolamento)

Data Access Builder dispone di un'API per l'impostazione del livello di isolamento del database sulla classe di datastore generata setTransactionIsolation(int).

Persistence Builder mantiene le proprie transazioni e supporta internamente i seguenti livelli di isolamento.

La transazione specifica il livello di isolamento Repeatable Read o Unrepeatable Read. L'implementazione del servizio per la classe business specifica l'implementazione di blocco o di non-blocco. Per ulteriori dettagli sulle differenze tra livelli, fare riferimento all'aiuto in linea di Persistence Builder.

I bean Data Access dispongono di un'API per l'impostazione del livello di isolamento del database. Questo è possibile specificando il livello di isolamento desiderato quando si forniscono le informazioni sul collegamento attraverso l'editor delle proprietà personali oppure attraverso il metodo DatabaseConnection.setTransactionIsolation().

Parte 3: Funzioni Data Access beans (DAB)

L'associazione per DAB si verifica tra tabelle e bean Select. Questa associazione tra una tabella e un bean Select non è 1:1 e perciò il bean Select non rappresenta la tabella. Tuttavia, i bean Select possono dimostrarsi molto utili per la gestione della riga corrente e di un insieme di risultati. E' possibile creare uno o due bean Select da utilizzare per eseguire operazioni base di programmazione di database su una tabella. Quindi, se si sta utilizzando DAX per operazioni di database come interrogazioni, lettura, scrittura, aggiornamento e cancellazione in un modo semplice e diretto, i DAB rappresentano una possibilità di sostituzione di DAX.

E' possibile interagire con i database impostando la proprietà query (che deriva dalle informazioni sul collegamento e dalle informazioni SQL Query) di un bean Select.  Le informazioni sul collegamento contenute nella proprietà query possono essere utilizzate da più di un bean select. E' possibile incorporare bean select nella propria codifica visivamente, utilizzando l'Editor di composizione visiva, oppure manualmente. 

Di seguito sono riportate le regole generali per la creazione di un bean Select Bean da utilizzare per gestire la riga corrente di una tabella customer. Per ulteriori dettagli su come eseguire questi passi, fare riferimento all'aiuto in linea:

  1. Aprire una classe nel VCE, creare un bean Select e aprire l'editor delle proprietà dell'interrogazione.  
  2. Immettere le necessarie informazioni sul collegamento e generare una classe di accesso al database.
  3. Specificare la classe di accesso al database. Aprire la SmartGuide SQL Assist.

  4. Selezionando la tabella customer e specificando la condizione che il numero customer (cusno) è esattamente uguale al parametro CUSTNUM, viene generato un bean Select per il customer. La classe di accesso al database per tale bean Select dovrebbe apparire simile a quanto segue:

Con questo bean Select, è possibile eseguire operazioni base di database (lettura, scrittura, aggiornamento e cancellazione) su una riga della tabella customer (quando il numero customer è specificato).  

Creazione di un secondo bean select

E' possibile creare un altro bean Select per lavorare con un insieme di risultati (cioé, eseguire un'interrogazione di database) mediante la stessa procedura e non specificando alcuna condizione. Questo secondo bean Select consente di sfruttare la funzionalità  dell'insieme di risultati DAB. La classe di accesso al database per tale bean Select dovrebbe apparire simile a quanto segue:

Bean Select e interrogazioni personali

DAB fornisce un forte supporto alla creazione di bean Select che utilizzano interrogazioni personali. Come descritto di seguito, la SmartGuide SQL Assist fornisce aiuto nella creazione di un'interrogazione di unione, nella specifica delle condizioni di un'interrogazione, nella selezione di colonne, nell'ordinamento di colonne e  nell'associazione di campi.

Bean Data Access e Procedure memorizzate

Il bean Procedure Call abilita alla gestione di procedure memorizzate. La creazione di un bean Procedure Call è simile alla creazione di un bean select. La SmartGuide per le procedure memorizzate elenca le procedure memorizzate disponibili.

Per ulteriori informazioni sull'utilizzo del bean Procedure Call, fare riferimento all'aiuto in linea relativo ai bean Data Access.

Copyright e Informazioni preliminari

© Copyright IBM Corp.1997, 2001. Tutti i diritti riservati.

Limitazioni per gli utenti appartenenti al governo degli Stato Uniti d'America -- L'utilizzo, la duplicazione o la divulgazione sono limitati dal supplemento GSA ADP al Contratto con l'IBM Corp.

Queste informazioni sono state sviluppate per i prodotti e i servizi offerti negli Stati Uniti. E' possibile che negli altri paesi l'IBM non offra i prodotti, le funzioni o i servizi illustrati in questo documento. Consultare il rappresentante IBM locale per informazioni sui prodotti e sui servizi attualmente disponibili nel proprio paese. Ogni riferimento relativo a prodotti, programmi o servizi IBM non implica che solo quei prodotti, programmi o servizi IBM possano essere utilizzati. In sostituzione a quelli forniti dall'IBM, possono essere usati prodotti, programmi o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale o di altri diritti dell'IBM. E' responsabilità dell'utente valutare e verificare la possibilità di utilizzare altri programmi e/o prodotti, fatta eccezione per quelli espressamente indicati dall'IBM.

Quanto riportato di seguito non vale nel Regno Unito o in qualsiasi altro paese in cui non sia compatibile con le leggi vigenti:

L'INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE QUESTA PUBBLICAZIONE "NELLO STATO IN CUI SI TROVA" SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITA' ED IDONEITA' AD UNO SCOPO SPECIFICO. Alcune nazioni non escludono le garanzie esplicite o implicite; di conseguenza la suddetta esclusione potrebbe, in questo caso, non essere applicabile. Questa pubblicazione potrebbe contenere imprecisioni tecniche o errori tipografici. Le informazioni incluse in questo documento vengono modificate su base periodica; tali modifiche verranno incorporate nelle nuove edizioni della pubblicazione. L'IBM può effettuare in qualsiasi momento miglioramenti e/o modifiche ai prodotti e/o programmi descritti in questa pubblicazione senza preavviso.

Tutti i riferimenti a siti Web non dell'IBM contenuti in questo documento sono forniti unicamente a scopo di consultazione.

Il contenuto di questi siti non rientra nella documentazione relativa al prodotto IBM in questione. Pertanto, l'utente si assume eventuali rischi per l'accesso a questi siti Web. L'IBM può utilizzare o divulgare le informazioni ricevute dagli utenti secondo le modalità ritenute appropriate, senza alcun obbligo nei loro confronti.Il programma su licenza descritto in questo documento e tutto il materiale su licenza ad esso relativo sono forniti dall'IBM nel rispetto delle condizioni previste dalla licenza d'uso.

IBM, AIX, AS/400, DB2, OS/390, OS/400, RS/6000, S/390, VisualAge e WebSphere sono marchi dell'IBM Corporation negli Stati Uniti e/o in altri paesi.

Lotus, Lotus Notes e Domino sono marchi della Lotus Development Corporation negli Stati Uniti e/o in altri paesi. Java e tutti i marchi e logo Java sono marchi della Sun Microsystems, Inc. negli Stati Uniti e/o in altri paesi. Microsoft, Windows e Windows NT sono marchi della Microsoft Corporation negli Stati Uniti e/o in altri paesi. Intel e Pentium sono marchi della Intel Corporation negli Stati Uniti e/o in altri paesi. Nomi di altri prodotti, società e servizi possono essere essere marchi o marchi di servizio di altre società.